|
Mr. Dog, the only way to kill all the distributions is to make them irrelevant. And slowly but surely, that's what they're trying to do. The bundle system is what every other OS does. Most of the time, it's going to be deduplicated. Fedora had a policy of preventing bundled libraries, and I can't imagine that will go away in the new world order. This is the policy that prevents users from using software like Chrome, so it's one of those bullshit policies that was thought up by a programmer and nobody thought about how it would impact users. I'm also concerned about btrfs, mostly because there's no full time maintainers or developers for it anymore. I'm going to sternly talk to Lennart about this, and to Colin about ostree's future. A lot of the goals here actually stemmed from the same internal project that Colin built ostree for, but ostree is a real thing that works, and Lennart's isn't.
|
#
?
Sep 1, 2014 15:54
|
|
|
|
| # ? Apr 26, 2024 14:10 |
|
|
raruler posted:Suspicious Dish, just make sure you're getting paid in cash and not equity or stock options or something. I chose the high cash, low equity option. Let me just say that six figures for an idiot, ignorant 22 year olds ain't bad.
|
|
#
?
Sep 1, 2014 15:56
|
|
|
Suspicious Dish posted:Mr. Dog, the only way to kill all the distributions is to make them irrelevant. And slowly but surely, that's what they're trying to do. this is why software vendors (including my employer) run or contract out (i.e. with package cloud) their apt/rpm/w/e repos, and ship a monolithic pckage that includes things like its own non-shared libraries
|
|
#
?
Sep 1, 2014 16:36
|
|
|
Progressive JPEG posted:maybe they should think more about fixing the cause (garbage libs whose regressions are going undetected/ignored) instead of the symptom (apps that use those garbage libs having version-specific problems) there's a guide on how to make proper shared libraries, almost nobody follows it. its purely an upstream problem.
|
|
#
?
Sep 1, 2014 17:34
|
|
|
Suspicious Dish posted:I'm also concerned about btrfs, mostly because there's no full time maintainers or developers for it anymore. looks like chris mason is still on it full time? he apparently switched companies again a while back but it sounds like theyre interested in him continuing to develop it
|
|
#
?
Sep 1, 2014 17:36
|
|
|
Mr Dog posted:this WinSxS-on-crack proposal is a technical solution for a political problem. i don't particularly like it because it's going to turn a flat fs hierarchy into a namespaced, aliased, hall-of-mirrors hell. it turns linux into sco opensewer you ready for /var/opt/K/SCO/link/1.1.1Eb/etc/conf/pack.d/merge/Driver.o ?
|
|
#
?
Sep 1, 2014 17:37
|
|
|
Suspicious Dish posted:I chose the high cash, low equity option. Let me just say that six figures for an idiot, ignorant 22 year olds ain't bad.
|
|
#
?
Sep 1, 2014 17:39
|
|
|
oh, and the reason Fedora has that unbundling policy is that they don't want to deal with hundreds of different upstream packages embedding vulnerable versions of zlib willy-nilly again
|
|
#
?
Sep 1, 2014 17:41
|
|
|
packaging multiple side-by-side versions is the correct solution to the problem, preferably using something along the lines of Semantic Versioning (completely separate from the Marketing Version Number) bundling and static-linking everything is the lazy lovely solution to the problem.
|
|
#
?
Sep 1, 2014 18:09
|
|
|
ok now that ive actually skimmed it more than 5s, it sounds neat overall but feels they just went through a checklist of fashionable modern fs features and tried to find ways to use them all the btrfs snapshotting dependency would avoid the extra effort of path handling hackery for the packages, yet the package format is still going to need some degree of author effort to specify eg the more granular dependency versions and to sign packages in the first place. feels like they may as well just gently caress with path handling and avoid the btrfs dependency overall i think the concept is neat and that itd be a good replacement for the sea of distro sperglord middlemen frequently ruining the author's work but i dont really see why it should require btrfs-specific features to function and i feel like it'd be a much easier sell if they didnt depend on that quote:One of them is actually signing/verification of images. The btrfs maintainers are working on adding this to the code base, but currently nothing exists. This functionality is essential though to come to a fully verified system where a trust chain exists all the way from the firmware to the apps. the finest openssl straight from the verified author oh i think i get it, theyre trying to allow getting rid of the 3rd party packager entirely and having the author diy it, okay thatd be pretty cool, tho it still looks a lil unclear how the chain of trust would work/scale to individual authors and lol if its also signed on dependencies such that even the os vendor cant push a zlib security update across the board without getting the approval of each author that touches zlib quote:Also, to make the home sub-volume scheme fully workable we actually need encrypted sub-volumes, so that the sub-volume's pass-phrase can be used for authenticating users in PAM. This doesn't exist either. depending on their definition of 'need' (this feature sounds pretty optional to me): - the default result of losing your user password is your data is gone, you cant just reboot onto a livecd. sure, if you encrypt your drives today and forget the pw you get this result, but its an additional optional step and the volume pw isnt necessarily the user pw - and lets just disregard otp or ldap (again they're sounding like they think encrypted home dirs is required)
|
|
#
?
Sep 1, 2014 18:20
|
|
|
Mr Dog posted:anyway kdbus and gnome sandboxes will solve this for the narrow case of desktop applications (which tbh nobody really cares about for linux anyway). so you'll have a sandboxed GNOME Weather applet and GNOME Music application that can be released to users directly via self-contained release ZIPs from upstream downloaded via the GNOME Software application. Great. NixOS solved this problem hermetic builds are gr8
|
|
#
?
Sep 1, 2014 18:30
|
|
|
Progressive JPEG posted:the btrfs snapshotting dependency would avoid the extra effort of path handling hackery for the packages, yet the package format is still going to need some degree of author effort to specify eg the more granular dependency versions and to sign packages in the first place. feels like they may as well just gently caress with path handling and avoid the btrfs dependency i mean the snapshotting stuff makes it cleaner but i think itd make more sense to treat the snapshotting as one way to implement an agnostic concept (one that could even work on normal dir structures if you really wanted), so that you arent tied to btrfs' style of snapshotting forever
|
|
#
?
Sep 1, 2014 19:06
|
|
|
if the """solution""" is copypasting a 600MB pile of (select one of Ubuntu Server, CentOS, SuSE, all fully loaded up to the gills with all the ancient Gtk1 utilities they install by default) dog poo poo for every application that I install onto my system, and then running a separate instance of mysql and apache and memcached and sshd and whatever with absolutely no way to share these system services or commonly administrate them then i think i'll keep the problem thank you. there you go i cured your strep throat by giving you ebola
|
|
#
?
Sep 1, 2014 19:06
|
|
|
Mr Dog posted:dog poo poo for every application
|
|
#
?
Sep 1, 2014 19:10
|
|
|
Mr Dog posted:there you go i cured your strep throat by giving you ebola a succinct description of every poettering mega-project
|
|
#
?
Sep 1, 2014 19:51
|
|
|
nah, this is what surprises me about this proposal actually poettering's usual style is "hey, this poo poo sucks, instead of stuffing it under the floorboards by piling brittle scraper and automation scripts on top of it why not actually fix this poo poo so that it doesn't suck" which is kind of the opposite of what's going on here
|
|
#
?
Sep 1, 2014 19:56
|
|
|
This isn't our first attempt at fixing this poo poo. It's a loving hard problem, with plenty of politics in the way. This is actually a model we want to move to, because it's what the world has already moved to, no matter what policies you stick in the way. Lennart is much more optimistic about the "runtime" situation working out: he imagines a GNOME SDK or a KDE SDK that app vendors will build on top of, and that's the common runtime for lots of apps. I think that a variety of issues, mostly social and political, will keep that from taking off.
|
|
#
?
Sep 1, 2014 20:15
|
|
|
Progressive JPEG posted:and lol if its also signed on dependencies such that even the os vendor cant push a zlib security update across the board without getting the approval of each author that touches zlib The article hints at security updates have to become n-fold updates for all the different major versions in use by applications. There is also finally acceptance that "security updates"-only sucks for users and vendors whom wish to push out new updates and are artificially held back. Thus an important part of the puzzle to come is how to fan-out of security patches to multiple versions.
|
|
#
?
Sep 2, 2014 03:08
|
|
|
MrMoo posted:Thus an important part of the puzzle to come is how to fan-out of security patches to multiple versions. we found a solution to that decades ago, it's called shared libs
|
|
#
?
Sep 2, 2014 12:28
|
|
|
systemd is really cool because the driving force behind it is "what if we took all the pain points of Linux and over engineered them to the point of being a completely different set of problems"
|
|
#
?
Sep 2, 2014 12:59
|
|
|
api call girl posted:we found a solution to that decades ago, it's called shared libs Shared library versioning is not fun.
|
|
#
?
Sep 2, 2014 14:20
|
|
|
ahmeni posted:systemd is really cool because the driving force behind it is "what if we took all the pain points of Linux and over engineered them to the point of being a completely different set of problems" I converted my "puttering-around" Linux into using systemd and I think I can best describe the idiocy by illustrating with the change from tail -f /var/log/syslog to uh journalctl -somethingorother so I installed rsyslog and got old functionality back 
|
|
#
?
Sep 2, 2014 16:21
|
|
|
yeah journalctl -f is so very hard to remember, especially since they deliberately chose that flag to be the same as tail -f
|
|
#
?
Sep 2, 2014 16:26
|
|
|
Suspicious Dish posted:FYI, here's the computers we're building. They run Linux. I like what yo uare doing the MISSION boxes look real pretty and remind me of this  (i could've sworn those radios were made by General)
|
|
#
?
Sep 2, 2014 16:46
|
|
|
reminds me more of a dieter rams thing 
|
|
#
?
Sep 2, 2014 17:03
|
|
|
Mr Dog posted:yeah journalctl -f is so very hard to remember, especially since they deliberately chose that flag to be the same as tail -f rsyslog is more about the poo poo that lives in and off of /var/log/ but ok journalctl is basically the archetypical overengineered solution, though I like -x VAGENDA OF MANOCIDE fucked around with this message at 17:06 on Sep 2, 2014 |
|
#
?
Sep 2, 2014 17:04
|
|
|
i mean it doesn't even matter, if you want the journal to forward to rsyslog then it'll do that, so go nuts. journal entries have a bunch of key-value stuff that is authenticated by the os in places where that makes sense, so you can look at, say, just the log output for a particular system service without having to grep the latest log and then zgrep logs 2 3 and 4 or whatever. or look at just the log entries for the latest boot or in a certain time span very easily. apparently syslog can do a bunch of this stuff and there's some rfcs standardising it and blah blah blah, no syslog as actually packaged in a shipping distro actually does this, journal does it out of the box. this is all useful poo poo that couldn't be made to work reliably before without scraping textual timestamps or parsing the ad-hoc record format of textual log file entries, that's not "over-engineered" that's "doing useful poo poo that people need that the previous solution wasn't really designed to do"
|
|
#
?
Sep 2, 2014 17:11
|
|
|
I really like that the journal is time-ordered and integrates all my 8 zillion log files together. Everything in Linux is loosely coupled which means that when one daemon stops working, all 8 thousand others also stop working, and piecing together the log files from every single one sucks. Sometimes they log to stderr, sometimes they log to syslog, sometimes they log to /var/log/butts, sometimes somewhere in their homedir, etc. Now they all log to the journal in a consistent format, all interlaced together, and I can even filter by cmdline, servicename, and date range as well. I don't think it's overengineered at all. It's complex, but the problem space is complex with a lot of needs from a lot of people. Think about how many shell scripts to womp log files there are in the world, and you'll realize that it's just a hard problem to solve.
|
|
#
?
Sep 2, 2014 17:55
|
|
|
current linux status: going thru fail2ban logs and pulling out subnets from the hundreds of temp banned IPs and just adding CIDR-wide blocks in iptables by hand forever. some of these are like /13s and poo poo. bye, china
|
|
#
?
Sep 2, 2014 19:14
|
|
|
configure your firewall to only allow ssh and other important services to be available from your office's subnet and/or production range and set up ssh to be key only and don't worry about fail2ban
|
|
#
?
Sep 3, 2014 09:49
|
|
|
my stepdads beer posted:configure your firewall to only allow ssh and other important services to be available from your office's subnet and/or production range fair enough quote:and set up ssh to be key only lol nope quote:and don't worry about fail2ban still good to use as a generalized service to kill all sorts of things, not just ssh
|
|
#
?
Sep 3, 2014 13:07
|
|
|
for example say you run a (properly configured) name server and some morons are trying to bounce ddos off of you their zombies don't care that you're not actually sending on the recursive lookup, but you're still seeing that poo poo in your incoming, and your logging fail2ban/recidive to the rescue
|
|
#
?
Sep 3, 2014 13:21
|
|
|
code:code:VAGENDA OF MANOCIDE fucked around with this message at 13:35 on Sep 3, 2014 |
|
#
?
Sep 3, 2014 13:25
|
|
|
i didn't know about the recidive filter that seems useful. i hope you all badger your network guys into turning on rpf or similar as well. I need to badger mine harder 
|
|
#
?
Sep 3, 2014 13:39
|
|
|
sounds like a real mission, bro
|
|
#
?
Sep 3, 2014 13:54
|
|
|
cheers bro
|
|
#
?
Sep 3, 2014 14:07
|
|
|
api call girl posted:lol nope Having a jump server key-only works wonders, then you can hide it behind .ssh/config and transparently hop into your servers.
|
|
#
?
Sep 3, 2014 14:17
|
|
|
lost my ~/.ssh/id_rsa welp, guess it's time to call the noc (or you could keep passwords enabled because lmao seriously?)
|
|
#
?
Sep 3, 2014 15:36
|
|
|
Mr Dog posted:lost my ~/.ssh/id_rsa you can have multiple allowed keys fyi worst case put one on a zip drive or smth e: plz dont generally reuse the same keyfile across multiple systems tia
|
|
#
?
Sep 3, 2014 17:02
|
|
|
|
| # ? Apr 26, 2024 14:10 |
|
|
MrMoo posted:Having a jump server key-only works wonders, then you can hide it behind .ssh/config and transparently hop into your servers. ok i can see the value in that
|
|
#
?
Sep 3, 2014 18:39
|
|