Storage needs to be detected on boot before the init system can do anything with it. That's going to effect when you can bring up other daemons, including network ones. Which in turn may require bringing up network connectivity so you can mount network filesystems that you may be booting from in the first place.
All of which needs to be done in accordance with the idea that we might not be booting, but instead coming out of hibernation or sleep mode, and we need to check that the world wasn't exploded around us while we were doing that (i.e. the network is still there, is still the same network, and the storage is still reachable or hasn't been hot plugged).
If you don't think cgroups are the responsibility of the init system though I don't even know what to say to that. That the process which launches all other processes shouldn't be able to request they be isolated, and monitor them to check they're still running?
Frankly, I don't know why people think these things aren't the domain of the init system. They are all absolutely fundamental activities of a modern computer system, which need to functional at the various levels of boot time when nothing else may be running.
Those people who know a better way also seem to have no intention to ever write any of the code themselves. It's open source: nothing's stopping them. Much as ultimately Linus did the hard work and Tennenbaum did not, such as it will be for whatever init system people want: the code which gets written gets run. Or in this case, the distro which is maintained gets used.
Frankly, you also cut back to my original point: character assassination and not technical discussion is not "a better way".
More over, this "how did it get corrupted" is the height of naivete. How did it get corrupted? On a random user system of unknown providence? Oh let me count the ways.
1. Hard disk developed a bad sector, wasn't redundant in anyway. Did you know mirror RAID in Linux doesn't actually have a mechanism to vote on the correct data, at least last time I checked? 2. Non ECC RAM suffered a random bit flip from a cosmic ray (8% per year, per chip, according to Google). 3. Bad SATA cables, power supply to the PC or any other thing (checkout people exploring the origin of errors with ZFS checksum faults to see the things that can happen).
So "why are the logs corrupted" - well, pick one. And then tell me how a text log that writes half a line of any data would fair any better.
People think plain text logs are somehow more intelligible in failure scenarios but never actually deal with them and likely never notice them since amongst other things, plain text logs include no hashes or checksums or any other type of actual error checking. Or to put it simply: google "corrupted logs" and see how often it happens to people's text logs.
That, and there are the corruptable binary logs, the solution to which in the bug report is to "just delete them" and the bug has been closed as won't fix. Sorry, but if this is the resposne to journal corruption rather than finding out WHY the journals get corrupted and fixing the fuckign problem, then i do not want that in control of my logfiles.
Log files are unimportant to the people who are writing and advocating for SystemD.
Logs files are criminally important to those who have to report to regulatory agencies and otherwise important to those who manage systems for others (businesses and governments). None of those agencies will accept missing, incomplete, or corrupted log files during an investigation.
The people writing this software need to get serious or get out. Logs are of vital importance.
It seems like I am surrounded by inexperienced children who have no adults to discipline them.
People who seem to think log files are so important sure seem to spend a lot of time not learning about log files in systemd before writing angry internet posts about them. Otherwise they'd know that you can forward text logs to any system you want with journald, and avoid the binary log format entirely. Which is information one can find out from say, man pages, Google or any of the sources I presume they consult when configuring such important log file storage systems.
I mean, I also assume they're up to speed on problems with syslog, like how by default the whole protocol is UDP and will drop packets freely?
>Sys-V is an utter shambles when automating that many machines.
That's funny it works for my broad spectrum workloads and systemd does not. Why do I not have a choice?
Funny I thought you did, since if you have "broad" workloads you probably have heavily customized a bunch of sys-v init scripts to boot up, and your upgrades are carefully planned affairs with tests, regression testing and a lot of preparation. In which case, why do you care? You're not blindly upgrading distros in the first place, so you're free to do what you want.
Yeah I mean, all those other people should just learn English really.
Do you realize how inane this is? In the same breath people ask "why bother? No one needs it" you're complaining that "oh it'll ruin my shortcut keys because I, personally, switch language all the time".
You know what doesn't work anywhere? Any of the shortcuts in my.bashrc file because I don't have the file on that specific computer. But you know what you could almost certainly do with a well localized terminal system? Quickly and easily change the language to the one you're familiar with. Exactly unlike the current situation if you don't speak American English.
Do you? Seriously, do you have a single, coherent and plausible reason that this is a bad idea, in some way which would not just as equally effect syslog or any other process which provides logging?
Binary log files are more compact. They can be better indexed. They lend themselves to localization more easily by abstracting the problem away from the executable that writes them. They can be strongly typed.
Frankly, you listed a bunch of tools which process "text logs" as though they're not doing exactly the same thing a binary log file tool is doing. They are also not "basic tools". Regex parsing is anything but basic, it's just commonly included. Just as journalctl will be on *any* system which uses journald because it's a basic tool.
There's also a huge strain of American-centrism here. Plain text sounds great so long as you assume it's English.
Seriously, people keep saying this and I am genuinely curious what these needs are, and how they're presently met with init scripts.
Because "advanced" uses server side tend to be "monitoring and surveillance" - two things systemd is actually really good at. Binary logs? Literally no one cares, because your logging is going over the network and into a database of some type anyway and sending a few bytes less is actually kind of a big deal.
What people call "rare" edge cases in it's detractors seems to include, amongst other things, hot pluggable storage, localization, power management, service monitoring, cgroup isolation, network connectivity for enterprise configuration...
If this was the case, why does he consistently reproduce it? Where are the failures? Does he only have one? Why has no one mentioned this failure rate? Or that it only works with material from a certain source? No one in science thinks these are unreasonable questions - they're usually very interesting!
There was a lot of work done finding the right source of talc for a particular medical procedure, because if they sourced it from somewhere else then it would turn out to be toxic. No one really knows why, although detailed study means we think it's now somewhat related to the -OH group concentration on the surface. Maybe.
The problem is, this isn't what's being relayed. Instead Rossi keeps details vague, because if you actually had details, you'd be able to go looking at the problem and actually do some science.
So it can't run a desktop. Or a laptop. Or any system where network status might change really.
It requires a whole min $50,000 a year employee to keep it running (sysadmin). You're going to write a separate HA failover daemon (or you're going to use...something that will look a lot like an init system).
You want to log to file but don't now if the disk is mounted, and writeable (again: how are you going to ensure this, what do you do if it fails?).
And this is just your simple network service. What about console services? Localization? Graphics? Drivers and daemons for hardware?
This is just a crazy suggestion, but maybe a normal computer is fairly complex since people want their computer to do a lot of things, and if you have such simple requirements, then you shouldn't be installing a desktop or (apparently in your example case) server OS. I would suggest a microcontroller. Of course even there you'll still need some type of bootloader to get things running...
More importantly: it's more expensive to do the same computations on old hardware then it is on new hardware, factoring capital and power expenses. Newer hardware is straight up better.
Yeah that seems...odd. Modern military small unit tactics are built entirely around volume of fire - it's why automatics were developed and modern service rifles are the way they are.
What services does your daemon provide? Will it rebind to network interfaces if they change? Does it need to write to disk? Does it need syslog to do logging output? If it crashes, should someone be notified? How? When? How often? Who?
And no one uses "command stream" style network rendering, nor is it actually faster, in 2014.
The only advantage X has over networked graphics is that you can forward the socket and have the app pop up in it's own window on your machine....but you can't detach and re-attach to it, or move it locally or remotely to another machine, and the actual rendering is effectively a very unnecessarily chatty bitmap stream anyway (hence why things like x2go are such huge improvements).
Remote apps and desktop on Linux *suck* compared to something like Remote Desktop on Windows, and it's absurd.
Wayland can easily, and has been shown to, support the same type of functionality, and can do it better and faster by simply sending a normal image stream.
Do they measure high frequency currents? Are all the wires accounted for and individual conductors measured? Are the path ways through the 3-phase power adequately monitored? Are their oscilloscopes hooked up to monitor the voltages (a good way to spot surreptitious activity via unusual waveforms)?
Of course their aren't.
So you've got an elaborate looking setup, which doesn't actually thoroughly cover the heat production aspect, and doesn't thoroughly cover all the electrical inputs to the system. There's a non-descript "power box" considered to not be part of the device under test, despite being supplied by the device inventor.
2 kW is less current then a standard single phase socket puts out. It is ably carried by 1mm or smaller conductors. There was a 3-phase power supply involved in this experiment, connected to something which is functionally a bar heater.
Not quite. But a resistive heater, yes.
The values for total power out that they computer are only in the 2200 W range - still practically doable by our aformentioned single phase power socket.
So yes, tiny is the correct word.
How do you figure? 2200 W for 720 hours straight is twice the amount of electric power a U.S. household consumes in the same period of time. No, I don't call that tiny. Why? Because allegedly it came from ONE GRAM of fuel. As I mentioned above, you have to account for the size of the source, when measuring whether it's tiny or large. It's all relative.
The experiment was carried out in Europe. Europe uses 220-240VAC. And yes: that's tiny. In the sense that they produced no value which is substantially larger then could have been trivially supplied through surreptitious means by miswired connections. Its not some big accomplishment to get 2kW in and out of something using regular electrical gear from a hardware store. It's not hard to get 720 hours out of that gear.
So no amount of energy in excess of what very conventional wiring and equipment can supply was delivered.
No that's one megawatt for one hour - which is why it's an incredibly weird thing to use for a month. For the length of a month that's equivalent to 2kW for 720 hours, assuming 30 days, so a LOT less than typically household usage.
Pardon me. The number I first found when I looked up average household usage was way off.
So... average U.S. household is about 10.5 MWH. This thing put out 1.5 MWH in one month (more or less). Multiply by 12 and you get 16 MWH, which is higher than the average in even the state with the highest average, LA, which is 15 MWH.
Still, again, it's anything but tiny. You have to account for the mass of the device. Even more so for the mass of the fuel.
You don't have a shred of evidence that it's a "con". Only guesses. And bad guesses at that. Not good enough.
2 kW is less current then a standard single phase socket puts out. It is ably carried by 1mm or smaller conductors. There was a 3-phase power supply involved in this experiment, connected to something which is functionally a bar heater.
The values for total power out that they computer are only in the 2200 W range - still practically doable by our aformentioned single phase power socket.
So you know, maybe it was producing 20 kW of power, maybe it was somehow only radiating 200 W on a 2kW input. Who knows? 2 orders of magnitude, you do get that that's a range of 10 to 1000 right?
No but the inventor who supplied a "power box" which was sitting in front of the 3-phase power to the device, and was on site for the setup and allowed to tamper with the device at various times very well could have.
People who haven't dealt with complex (literally) power systems always chronically underestimate how many ways you can get power into a system which will not be obviously represented as volts and amps via measurement devices.
Slashdot Mirror
Storage needs to be detected on boot before the init system can do anything with it. That's going to effect when you can bring up other daemons, including network ones. Which in turn may require bringing up network connectivity so you can mount network filesystems that you may be booting from in the first place.
All of which needs to be done in accordance with the idea that we might not be booting, but instead coming out of hibernation or sleep mode, and we need to check that the world wasn't exploded around us while we were doing that (i.e. the network is still there, is still the same network, and the storage is still reachable or hasn't been hot plugged).
If you don't think cgroups are the responsibility of the init system though I don't even know what to say to that. That the process which launches all other processes shouldn't be able to request they be isolated, and monitor them to check they're still running?
Frankly, I don't know why people think these things aren't the domain of the init system. They are all absolutely fundamental activities of a modern computer system, which need to functional at the various levels of boot time when nothing else may be running.
Those people who know a better way also seem to have no intention to ever write any of the code themselves. It's open source: nothing's stopping them. Much as ultimately Linus did the hard work and Tennenbaum did not, such as it will be for whatever init system people want: the code which gets written gets run. Or in this case, the distro which is maintained gets used.
Frankly, you also cut back to my original point: character assassination and not technical discussion is not "a better way".
More over, this "how did it get corrupted" is the height of naivete. How did it get corrupted? On a random user system of unknown providence? Oh let me count the ways.
1. Hard disk developed a bad sector, wasn't redundant in anyway. Did you know mirror RAID in Linux doesn't actually have a mechanism to vote on the correct data, at least last time I checked?
2. Non ECC RAM suffered a random bit flip from a cosmic ray (8% per year, per chip, according to Google).
3. Bad SATA cables, power supply to the PC or any other thing (checkout people exploring the origin of errors with ZFS checksum faults to see the things that can happen).
So "why are the logs corrupted" - well, pick one. And then tell me how a text log that writes half a line of any data would fair any better.
People think plain text logs are somehow more intelligible in failure scenarios but never actually deal with them and likely never notice them since amongst other things, plain text logs include no hashes or checksums or any other type of actual error checking. Or to put it simply: google "corrupted logs" and see how often it happens to people's text logs.
That, and there are the corruptable binary logs, the solution to which in the bug report is to "just delete them" and the bug has been closed as won't fix. Sorry, but if this is the resposne to journal corruption rather than finding out WHY the journals get corrupted and fixing the fuckign problem, then i do not want that in control of my logfiles.
Log files are unimportant to the people who are writing and advocating for SystemD.
Logs files are criminally important to those who have to report to regulatory agencies and otherwise important to those who manage systems for others (businesses and governments). None of those agencies will accept missing, incomplete, or corrupted log files during an investigation.
The people writing this software need to get serious or get out. Logs are of vital importance.
It seems like I am surrounded by inexperienced children who have no adults to discipline them.
People who seem to think log files are so important sure seem to spend a lot of time not learning about log files in systemd before writing angry internet posts about them. Otherwise they'd know that you can forward text logs to any system you want with journald, and avoid the binary log format entirely. Which is information one can find out from say, man pages, Google or any of the sources I presume they consult when configuring such important log file storage systems.
I mean, I also assume they're up to speed on problems with syslog, like how by default the whole protocol is UDP and will drop packets freely?
>Sys-V is an utter shambles when automating that many machines.
That's funny it works for my broad spectrum workloads and systemd does not. Why do I not have a choice?
Funny I thought you did, since if you have "broad" workloads you probably have heavily customized a bunch of sys-v init scripts to boot up, and your upgrades are carefully planned affairs with tests, regression testing and a lot of preparation. In which case, why do you care? You're not blindly upgrading distros in the first place, so you're free to do what you want.
Moreover the presenter is asked repeatedly if he's okay with the exchange continuing by someone (an organizer I presume).
Yeah I mean, all those other people should just learn English really.
Do you realize how inane this is? In the same breath people ask "why bother? No one needs it" you're complaining that "oh it'll ruin my shortcut keys because I, personally, switch language all the time".
You know what doesn't work anywhere? Any of the shortcuts in my .bashrc file because I don't have the file on that specific computer. But you know what you could almost certainly do with a well localized terminal system? Quickly and easily change the language to the one you're familiar with. Exactly unlike the current situation if you don't speak American English.
Do you? Seriously, do you have a single, coherent and plausible reason that this is a bad idea, in some way which would not just as equally effect syslog or any other process which provides logging?
A tiny minority. People who apparently are going to maintain a fork, but "don't have time to deal with Debian".
What do they think maintaining a distro involves, other then a lot of time working on procedure, process and politics?
The fact you feel the need to engage in character assassination rather then technical discussion speaks volumes about you yourself.
Binary log files are more compact. They can be better indexed. They lend themselves to localization more easily by abstracting the problem away from the executable that writes them. They can be strongly typed.
Frankly, you listed a bunch of tools which process "text logs" as though they're not doing exactly the same thing a binary log file tool is doing. They are also not "basic tools". Regex parsing is anything but basic, it's just commonly included. Just as journalctl will be on *any* system which uses journald because it's a basic tool.
There's also a huge strain of American-centrism here. Plain text sounds great so long as you assume it's English.
Such as?
Seriously, people keep saying this and I am genuinely curious what these needs are, and how they're presently met with init scripts.
Because "advanced" uses server side tend to be "monitoring and surveillance" - two things systemd is actually really good at. Binary logs? Literally no one cares, because your logging is going over the network and into a database of some type anyway and sending a few bytes less is actually kind of a big deal.
What people call "rare" edge cases in it's detractors seems to include, amongst other things, hot pluggable storage, localization, power management, service monitoring, cgroup isolation, network connectivity for enterprise configuration...
If this was the case, why does he consistently reproduce it? Where are the failures? Does he only have one? Why has no one mentioned this failure rate? Or that it only works with material from a certain source? No one in science thinks these are unreasonable questions - they're usually very interesting!
There was a lot of work done finding the right source of talc for a particular medical procedure, because if they sourced it from somewhere else then it would turn out to be toxic. No one really knows why, although detailed study means we think it's now somewhat related to the -OH group concentration on the surface. Maybe.
The problem is, this isn't what's being relayed. Instead Rossi keeps details vague, because if you actually had details, you'd be able to go looking at the problem and actually do some science.
So it can't run a desktop. Or a laptop. Or any system where network status might change really.
It requires a whole min $50,000 a year employee to keep it running (sysadmin). You're going to write a separate HA failover daemon (or you're going to use...something that will look a lot like an init system).
You want to log to file but don't now if the disk is mounted, and writeable (again: how are you going to ensure this, what do you do if it fails?).
And this is just your simple network service. What about console services? Localization? Graphics? Drivers and daemons for hardware?
This is just a crazy suggestion, but maybe a normal computer is fairly complex since people want their computer to do a lot of things, and if you have such simple requirements, then you shouldn't be installing a desktop or (apparently in your example case) server OS. I would suggest a microcontroller. Of course even there you'll still need some type of bootloader to get things running...
More importantly: it's more expensive to do the same computations on old hardware then it is on new hardware, factoring capital and power expenses. Newer hardware is straight up better.
Yeah that seems...odd. Modern military small unit tactics are built entirely around volume of fire - it's why automatics were developed and modern service rifles are the way they are.
What services does your daemon provide? Will it rebind to network interfaces if they change? Does it need to write to disk? Does it need syslog to do logging output? If it crashes, should someone be notified? How? When? How often? Who?
And no one uses "command stream" style network rendering, nor is it actually faster, in 2014.
The only advantage X has over networked graphics is that you can forward the socket and have the app pop up in it's own window on your machine....but you can't detach and re-attach to it, or move it locally or remotely to another machine, and the actual rendering is effectively a very unnecessarily chatty bitmap stream anyway (hence why things like x2go are such huge improvements).
Remote apps and desktop on Linux *suck* compared to something like Remote Desktop on Windows, and it's absurd.
Wayland can easily, and has been shown to, support the same type of functionality, and can do it better and faster by simply sending a normal image stream.
What does "sophisticated" mean?
Do they measure high frequency currents? Are all the wires accounted for and individual conductors measured? Are the path ways through the 3-phase power adequately monitored? Are their oscilloscopes hooked up to monitor the voltages (a good way to spot surreptitious activity via unusual waveforms)?
Of course their aren't.
So you've got an elaborate looking setup, which doesn't actually thoroughly cover the heat production aspect, and doesn't thoroughly cover all the electrical inputs to the system. There's a non-descript "power box" considered to not be part of the device under test, despite being supplied by the device inventor.
2 kW is less current then a standard single phase socket puts out. It is ably carried by 1mm or smaller conductors. There was a 3-phase power supply involved in this experiment, connected to something which is functionally a bar heater.
Not quite. But a resistive heater, yes.
The values for total power out that they computer are only in the 2200 W range - still practically doable by our aformentioned single phase power socket.
So yes, tiny is the correct word.
How do you figure? 2200 W for 720 hours straight is twice the amount of electric power a U.S. household consumes in the same period of time. No, I don't call that tiny. Why? Because allegedly it came from ONE GRAM of fuel. As I mentioned above, you have to account for the size of the source, when measuring whether it's tiny or large. It's all relative.
The experiment was carried out in Europe. Europe uses 220-240VAC. And yes: that's tiny. In the sense that they produced no value which is substantially larger then could have been trivially supplied through surreptitious means by miswired connections. Its not some big accomplishment to get 2kW in and out of something using regular electrical gear from a hardware store. It's not hard to get 720 hours out of that gear.
So no amount of energy in excess of what very conventional wiring and equipment can supply was delivered.
No that's one megawatt for one hour - which is why it's an incredibly weird thing to use for a month. For the length of a month that's equivalent to 2kW for 720 hours, assuming 30 days, so a LOT less than typically household usage.
Pardon me. The number I first found when I looked up average household usage was way off.
So... average U.S. household is about 10.5 MWH. This thing put out 1.5 MWH in one month (more or less). Multiply by 12 and you get 16 MWH, which is higher than the average in even the state with the highest average, LA, which is 15 MWH.
Still, again, it's anything but tiny. You have to account for the mass of the device. Even more so for the mass of the fuel.
You don't have a shred of evidence that it's a "con". Only guesses. And bad guesses at that. Not good enough.
2 kW is less current then a standard single phase socket puts out. It is ably carried by 1mm or smaller conductors. There was a 3-phase power supply involved in this experiment, connected to something which is functionally a bar heater.
The values for total power out that they computer are only in the 2200 W range - still practically doable by our aformentioned single phase power socket.
So yes, tiny is the correct word.
So you know, maybe it was producing 20 kW of power, maybe it was somehow only radiating 200 W on a 2kW input. Who knows? 2 orders of magnitude, you do get that that's a range of 10 to 1000 right?
No but the inventor who supplied a "power box" which was sitting in front of the 3-phase power to the device, and was on site for the setup and allowed to tamper with the device at various times very well could have.
People who haven't dealt with complex (literally) power systems always chronically underestimate how many ways you can get power into a system which will not be obviously represented as volts and amps via measurement devices.
Then build a 10kW one. Plenty of generators on that scale which can be had for a reasonable amount of capital.