|
Shinku ABOOKEN posted:i thought systemd is backwards compatible?? 1) lol b) not, as far as I'm aware, with upstart (yes I don't use debian but I'm still annoyed about systemd) iii) it's not backwards compatible with our log collector
|
#
?
Oct 17, 2014 19:14
|
|
|
|
| # ? May 10, 2024 13:37 |
|
|
Zombywuf posted:1) lol It has SysV compatibility, and you can continue to use rsyslog together with systemd if that's what your log collector took as input.
|
|
#
?
Oct 17, 2014 20:13
|
|
|
Also why are you converting running systems to systemd instead of leaving them as-is
|
|
#
?
Oct 17, 2014 20:18
|
|
|
api call girl posted:Also why are you converting running systems to systemd instead of leaving them as-is Fortunately I can put it off till 14.04 expires. But it's still there, waiting for me.
|
|
#
?
Oct 17, 2014 21:37
|
|
|
pram posted:may the lord visit extreme violence upon the creator of this all steves ways are peace
|
|
#
?
Oct 17, 2014 22:28
|
|
|
i want solaris smf on linux
|
|
#
?
Oct 17, 2014 22:32
|
|
|
Zombywuf posted:Fortunately I can put it off till 14.04 expires. But it's still there, waiting for me. it's not the startup way
|
|
#
?
Oct 18, 2014 00:00
|
|
|
ShadowHawk posted:it seems like you expect to still be in business in 5 years Been in business for 8 or 9 years. We're not in silicon valley so people don't just throw money at us for making mobile chat clients.
|
|
#
?
Oct 18, 2014 00:05
|
|
|
Notorious b.s.d. posted:i want solaris smf on linux because systemd is great and all, but what it was really missing all along was assloads of xml that's how you know it's enterprise
|
|
#
?
Oct 18, 2014 00:17
|
|
|
lol what the gently caress you run your poo poo on Ubuntu Server you deserve to see your IT infrastructure go down in flames, get RHEL (or CentOS if you're a goddamn cheapskate) jfc
|
|
#
?
Oct 18, 2014 00:18
|
|
|
Mr Dog posted:because systemd is great and all, but what it was really missing all along was assloads of xml don't forget that the XML is imported into a binary database which renders the system non-functional when it gets corrupted
|
|
#
?
Oct 18, 2014 00:22
|
|
|
Mr Dog posted:you deserve to see your IT infrastructure go down in flames, get RHEL (or CentOS if you're a goddamn cheapskate) jfc I do so love using software from 5 years ago. And our infrastructure goes down in flames regularly, we use EC2.
|
|
#
?
Oct 18, 2014 00:23
|
|
|
what bleeding-edge software do you need on a server exactly? absolutely latest and greatest postgres? like i'm genuinely curious here get puppet to install your jvm or plang interpreter and load ur poo poo on top of that, i'm sure installing up-to-date versions of those things on such an obscure and esoteric linux server distribution as the latest-but-one version of RHEL is not an insurmountable problem.
|
|
#
?
Oct 18, 2014 00:36
|
|
|
pseudorandom name posted:don't forget that the XML is imported into a binary database which renders the system non-functional when it gets corrupted well the journal has an explicitly undocumented binary format that i'm sure holds up just swimmingly when a data corruption event shits garbage over a few disk blocks here and there so we're already on the right track  that's like the one thing i don't like about systemd. and it's not even that hard to fix that particular aspect of it: byte-stuffing and delimiting the records and appending a checksum of appropriate strength is one potential mitigation that comes to mind immediately, but why do i get the feeling they haven't even done that. with an ASCII syslog it's trivial to resynchronize the record stream: break it into chunks along ASCII LF boundaries and let the squishy human figure it out. I'm guessing the binary syslog parser library just goes "welp, poo poo's hosed, sucks to be you, you should have kept backups CLOSED WONTFIX" instead. (I get WHY there's a fast indexed binary syslog but journald really ought to have at least an option to write a nice robust ASCII version in parallel as well instead of requiring me to run two semi-redundant logging daemons to do this)
|
|
#
?
Oct 18, 2014 00:42
|
|
|
Mr Dog posted:what bleeding-edge software do you need on a server exactly? absolutely latest and greatest postgres? like i'm genuinely curious here For reasons that are complicated to get into, Qt and other GUI poo poo that may or may not technically be under NDA. Have you any idea what it's like trying to jam a new GUI lib on an old distro? It's not fun. There's a reason this latest thing targeted the Gnome packaging. quote:get puppet to install your jvm or plang interpreter and load ur poo poo on top of that, i'm sure installing up-to-date versions of those things on such an obscure and esoteric linux server distribution as the latest-but-one version of RHEL is not an insurmountable problem. Cos I love having to install a bunch of poo poo every time I boot an instance. I'd rather just make an ami that runs stuff on boot, we made the mistake of assuming Upstart would be supported for a while.
|
|
#
?
Oct 18, 2014 00:59
|
|
|
Mr Dog posted:what bleeding-edge software do you need on a server exactly? absolutely latest and greatest postgres? like i'm genuinely curious here lol if you don't use postgres own rpm and deb repositories for the latest and greatest updates
|
|
#
?
Oct 18, 2014 01:05
|
|
|
Lennart pls create systemd-install. Use some combination of the RPM and deb formats but replace freeform install scripts with a strictly declarative and pre-determined set of secure actions that can be extended in later revisions of the standard. Express dependencies in terms of semantically-versioned shared library file names, specific versions of plang interpreters, and D-Bus interface names. Make different versions of the shared libraries and plang interpreters side-by-side installable, and don't bastardise the FHS into some horrible hall-of-mirrors to do it, you can do better than this. Distributions can then add their own proprietary metadata and dependency extensions just as long as they're backwards compatible with the common basic package format, reducing them to packaging a small core of long-term-supported system applications atop which upstream-packaged desktop environments, desktop software, and server applications can be installed. Boom, final nail in the coffin to make distributions completely irrelevant.
|
|
#
?
Oct 18, 2014 01:14
|
|
|
pls don't joke about that, I'm triggered by systemd expansion
|
|
#
?
Oct 18, 2014 01:54
|
|
|
Mr Dog posted:what bleeding-edge software do you need on a server exactly? absolutely latest and greatest postgres? like i'm genuinely curious here this should come from your postgres vendor postgresql.org runs a yum repo enterprisedb distributes binaries etc Mr Dog posted:get puppet to install your jvm or plang interpreter and load ur poo poo on top of that, i'm sure installing up-to-date versions of those things on such an obscure and esoteric linux server distribution as the latest-but-one version of RHEL is not an insurmountable problem. if you want support for new jvm/plang interpreters on old rhel red hat will happily do that for you thanks to the magic of ~*~ software collections ~*~ e.g. python 2.7 on rhel 5 is A Thing now the only catch is that you only get a guaranteed 1 year of support for the scl, instead of the 10 years you get with the base system. the scl might be a moving target every couple years still better than ubuntu
|
|
#
?
Oct 18, 2014 02:35
|
|
|
Mr Dog posted:lol what the gently caress you run your poo poo on Ubuntu Server
|
|
#
?
Oct 18, 2014 02:35
|
|
|
agreed
|
|
#
?
Oct 18, 2014 03:46
|
|
|
Yo I really only run minor servers for my own nagios and logstash poo poo, and then we needed to replace a webserver for v low stakes internal crap but I built them on Ubuntu, Debian, and then centos in that order because I learned things 
|
|
#
?
Oct 18, 2014 04:47
|
|
|
didnt read
|
|
#
?
Oct 18, 2014 05:10
|
|
|
ubuntu is bad
|
|
#
?
Oct 18, 2014 05:11
|
|
|
pram posted:ubuntu is bad same but ur posting
|
|
#
?
Oct 18, 2014 05:13
|
|
|
Mr Dog posted:well the journal has an explicitly undocumented binary format that i'm sure holds up just swimmingly when a data corruption event shits garbage over a few disk blocks here and there so we're already on the right track Nope. It's a journaling system (that's why it's called the journal), so it's entirely possible to recover from corrupted binary logs. And it is checksummed. And cryptographically verified.
|
|
#
?
Oct 18, 2014 05:23
|
|
|
Mr Dog posted:Lennart pls create systemd-install. Use some combination of the RPM and deb formats but replace freeform install scripts with a strictly declarative and pre-determined set of secure actions that can be extended in later revisions of the standard. Express dependencies in terms of semantically-versioned shared library file names, specific versions of plang interpreters, and D-Bus interface names. Make different versions of the shared libraries and plang interpreters side-by-side installable, and don't bastardise the FHS into some horrible hall-of-mirrors to do it, you can do better than this. Distributions can then add their own proprietary metadata and dependency extensions just as long as they're backwards compatible with the common basic package format, reducing them to packaging a small core of long-term-supported system applications atop which upstream-packaged desktop environments, desktop software, and server applications can be installed. did you see http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
|
|
#
?
Oct 18, 2014 05:24
|
|
|
Suspicious Dish posted:Nope. It's a journaling system (that's why it's called the journal), so it's entirely possible to recover from corrupted binary logs. And it is checksummed. And cryptographically verified. but don't let that stop these guys from xpoettering that binary blob bs complaint never made sense so wait we've got xml base files and a journaling system and you're complaining that it's making an intermediary binary blob thing to run off of? what? oh no file corruption! that can't be restored by your journaling fs! I'm sure at that point you've got more bare metal things to worry about than systemd throwing a poo poo and rebuilding some binary blob somewhere from component parts! VAGENDA OF MANOCIDE fucked around with this message at 05:43 on Oct 18, 2014 |
|
#
?
Oct 18, 2014 05:41
|
|
|
and let's face it anybody who's worried about file corruption taking out their syslog is probably not doing anything important with that info to begin with
|
|
#
?
Oct 18, 2014 05:50
|
|
|
Suspicious Dish posted:Nope. It's a journaling system (that's why it's called the journal), so it's entirely possible to recover from corrupted binary logs. And it is checksummed. And cryptographically verified. it isn't, though? looking at the spec which I'm not going to link or quote because I'm phone posting, only one of the record types has a hash, records are variable length and they don't have magic numbers, which means if you lose a chunk in the middle of the journal, the journal parser can't resynchronize and interpret the records after the damage
|
|
#
?
Oct 18, 2014 05:57
|
|
|
api call girl posted:oh no file corruption! that can't be restored by your journaling fs! I'm sure at that point you've got more bare metal things to worry about than systemd throwing a poo poo and rebuilding some binary blob somewhere from component parts! linux systems typically do not have journaling enabled for fs data, only metadata. in a hard power-off on a normal ext3/ext4 fs, poo poo is gonna be 1990s-grade crash consistent. metadata is certain to be correct, but any given block in a file might be out of sync
|
|
#
?
Oct 18, 2014 06:28
|
|
|
i sure hope every distro shipping systemd uses ext4 exclusively, and defaults to data=journal (they aren't)
|
|
#
?
Oct 18, 2014 06:30
|
|
|
Suspicious Dish posted:Nope. quote:It's a journaling system (that's why it's called the journal), Oh man, Lennart's updated the bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 It seems the only way to handle log corruption is to just give up, not recover from the journal. quote:And it is checksummed. And cryptographically verified. Well, it's timestamped every 15 minutes. That timestamping might even be secure. Assuming the attacker doesn't have write access to the log files.
|
|
#
?
Oct 18, 2014 11:21
|
|
|
Zombywuf posted:Oh man, Lennart's updated the bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 what he actually says there is that they perform whatever recovery is possible every time you read the corrupted file. they just don't write the recovered data back to the file, so the corruption isn't "fixed". I hate lennart and all his foul works as much as any angry graybeard who thinks Unix reached perfection decades ago and everything since has been a regression, but even so, this doesn't sound too unreasonable.
|
|
#
?
Oct 18, 2014 11:46
|
|
|
Soricidus posted:what he actually says there is that they perform whatever recovery is possible every time you read the corrupted file. they just don't write the recovered data back to the file, so the corruption isn't "fixed". Perhaps if you ignore the last 30 years of databases.
|
|
#
?
Oct 18, 2014 11:48
|
|
|
Zombywuf posted:Perhaps if you ignore the last 30 years of databases. if your syslog is that critically important maybe don't keep just the one binary copy sitting on the one local machine "attacker" lol yeah if they got write privileges as root you've got better poo poo to be worrying about than whatever traces they left in local syslog come on son
|
|
#
?
Oct 18, 2014 14:45
|
|
|
Mr Dog posted:on the plus side, the lwn reaction to this latest shitfit is overwhelmingly negative. i'd have at least some respect for the whiners if they actually wrote any code in the last six months instead of just bitching and demanding that everything remain the same. ya lwn is Good
|
|
#
?
Oct 18, 2014 15:41
|
|
|
Progressive JPEG posted:ya lwn is Good
|
|
#
?
Oct 18, 2014 15:44
|
|
|
api call girl posted:if your syslog is that critically important maybe don't keep just the one binary copy sitting on the one local machine yeah, if i wanted to keep my data, maybe i should have written it to persistent storage! like a disk or something!
|
|
#
?
Oct 18, 2014 16:46
|
|
|
|
| # ? May 10, 2024 13:37 |
|
|
gnome 3.14 trip report -- it sucks. if this had been 3.00 beta release #1, this would be ok. but it's the eighth stable release after three years, and tons of poo poo doesn't work backstory: i bought one of those windows 8 convertible laptop/tablet doohickeys. in "tablet" mode it has a windows key, a volume up, and a volume down, and that's it. gnome 3.14 on fedora 21 successfully configures the touchscreen as a multitouch absolute-positioning mouse. so far so good. upgrading to gnome 3.14 gets me the onscreen keyboard automatically in most of the right places most of the time. but only in gtk 3 applications. if you want to run an application that isn't gnome 3 native, you are screwed. notably firefox and chrome are not gtk3 if the automatic launch isn't working, there is no way to manually launch the on-screen keyboard w/out having a keyboard already. you have to bind a keyboard shortcut to open it. i said, "ok, that's dumb, but ok" and attempted to bind it to the windows key. no dice. gnome 3 will not allow you to use a modifier key as a keybinding alone. so i decided to give up on actual good web browsers and try the shitbucket that comes with gnome 3: epiphany. to my delight, epiphany does in fact support autoloading the on-screen keyboard like other gnome 3 native apps. unfortunately typing into the url bar immediately breaks because the autocomplete box pops up over top of the on-screen keyboard it is really, really obvious that nobody ever tried this on a tablet, not even once it is rough around the edges even by open sores standards. basic features do not work, the things that do work do not work consistently (i often clicked in a text field and got no keyboard, only to repeat and get the keyboard back)
|
|
#
?
Oct 18, 2014 16:57
|
|