The whole premise of the Foundation series is obsolete. The premise was that it was possible to predict the future to a moderate level of detail by calculation. Now that vast efforts have been expended in that direction by the weather and financial communities, we have a reasonably clear understanding of what can and cannot be accomplished in the prediction department. We know now that little changes grow into big ones (the "butterfly effect") rather than being filtered out. The future is driven by unpredictable noise.
Hardly obsolete. Validated, if anything. The modern-day psychomathematics is just Big Data and statistical analysis rules. The book gets thicker every day, and the NSA is based on it. So is corporate marketing.
Asimov also realized that a butterfly could run the train off the rails, which is why Seldon didn't merely work out the mathematics and turn it all loose. The Second Foundation existed precisely to apply compensating forces and to re-calculate the math as time unfolded.
I Robot had nothing to do with the book. It was in fact written on another title first and then they bought the name to slap on it because people would recognize it, and, hey, it's about robots, right? A bit of script touch-up to change a few names (gotta have Susan Calvin, although of course she won't be plain) and put in a few references to Asimov's concepts, and we're done!
I love Will Smith, and the movie was quite the spectacular, but Asimov would have had an aneurysm.
Asimov was actually more of a mystery writer than a straight-up SF author. He wrote straight mystery novels, too, but then he wrote something for every aisle of the Dewey Decimal System. The robot stories are almost all mysteries, and quite a few of them were murder mysteries, where a robot was apparently at fault despite the Three Laws. The riddle was how to explain what happened without violating those laws.
The movie said "screw it - the robot dunnit" and thereby took the easy way out.
It might have been forgivable if the lessons of that story were what caused the formulation of the 3 laws - I Robot, II. But no such implication was made that I saw. And regardless, it was still taking the easy way out.
Asimov could have managed to cause Calvin to envisage the 3 laws and STILL let the robot off the hook.
Asimov never aspired to be Science Fiction's God of Sex - he left that for Heinlein. But the only reason that the original foundation was so tame was because no one had sex back then.
He wrote very differently once the 1970's rolled in and had some very outspoken views on sex, the evolution of marriage, and other consequences of the century's improvements in lifespan, birth and disease control.
Foundation was not really prudish, but Asimov really didn't include (any that I recall) blatant sex scenes or sexual themes in his books, at least directly.
It's true, though. IDEs full of wizards and other magic make it look like less-capable (cheaper) people can do software. So that's what management hires.
Problem is, the IDEs can make a capable developer's job easier, but an incapable developer becomes utterly lost when the IDE falls short or breaks down.
but once you fail the drug test for traces opiates you are guilty until proven innocent
No, in post 1980s America, you are guilty of lots of things until you prove yourself innocent. And not "once you fail the drug test", because the test was given under the presumption you're guilty to begin with. Is testing for explosives residues on your hands a pre-condition for employment? Not yet, anyway.
Before Reagan promised to "get the government off the backs of the people", you didn't routinely find employers requiring drug tests. Nor did you have to prove up front that you weren't an illegal alien. Which, incidentally, doesn't seem to have done much from keeping employers from actually hiring illegal aliens.
But there you have it. If you were born after 1980, you've been a presumed criminal all your life.
You know what amuses me about all this systemd hate. Fedora was the first distro to go systemd by default back in F15. There were a few growing pains, but there wasn't the coordinated systemd hatred until pretty much recently when RHEL7 went out the door and debian said we're going systemd.
Well, some of it was simply that I had better things to do with my time than upgrade Fedora.
Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better.
That's nice. Let me know when you start getting a large number of companies agreeing with you. Part of the whole "keeping down the rank and file" in the wage category is making them believe they are easily replaceable cogs.
AH yes, but the Libertarian approach says that you stand up and tell them that you are not. That you have a proven record of excellence. And that you'll refuse to accept their puny offerings. Which, in the spirit of true market arbitration will cause them to reconsider.
Like hiring sports teams in what sense? Like the NFL draft? Big companies get to pick who they want from each year's graduating class, with little if any choice on the part of the new-minted engineers, and most of the graduates don't ever get to use their skills professionally?
When we hire we look for specific skills that are relevant to our business. Maybe that's what you mean. We try to be careful about what's an absolute must (e.g. knows C++) and make the rest of the qualifications "preferred" or "desired." We rarely get an exact match between what we'd like to have and the candidate but that's OK. We hire people that can learn.
The All-American institution NFL is rather socialist, actually. Unlike pro baseball, the richest team doesn't get all the marbles, because of salary caps and the draft ordering process that says that the teams with the worst previous-season record get preferred picks. There's a also a quite respectable minimum salary just for being on the team at all.
Baseball comes in tiers. If you don't make the majors, you still might find something on one of the farm team levels, You earn progressively less as you go down, but then we like to claim the USA is a meritocracy.
And yes, we all know that there are some people who deserve to wash out. People are not all equally suited and it's better for the marginal cases to look for something they'd be better at.
Seriously. The whole concept of business organization is stuck in the factory mentality of 200 years ago. People aren't interchangeable cogs and business needs to stop considering them as such. Cogs don't care about the business any more than business cares about the individual cogs.
Sports teams aren't the only alternative model that could be considered - after all Fred Brooks suggested a surgical team organization back in the 1960s. But the world is on the brink of major changes and we need to consider all the possibilities we can.
My personal favorite - and one I was dinged on several times before I learned to basically just lie my ass off about it - was how many servers I've been responsible for at one time. At some ISP jobs I've had, I've had to touch hundreds of unique servers while helping clients, but only had maybe 20-30 to worry about day to day. But companies hiring based on this metric want to hear that you were administering 200+, 500+, whatever number of servers on a daily basis. This is bullshit for two main reasons:
1. No single person is personally touching dozens or hundreds of servers on a daily or even weekly basis. A _team_ of people might, but a person isn't.
My take on this is that if there are 200+ servers, any on of which you may be required to service, the fact that you don't "touch" them all daily doesn't matter and that there's no lie involved here.
That's like rating the fire department on the number of houses they visit instead of the number of houses they protect.
The more servers you have to touch on a daily basis, the more likely that they're not well-configured.
Let the market decide. If DRM angers you, don't buy games from companies that use DRM.
The issue with the Religion of the Market is that it's really quite incredible the amount of abuse that people will accept when there's only one source for a product. Or, for that matter, just to get the Low Price Always.
I'd vote for quality of life myself, but the Market is against me.
BASIC had its day. The original BASIC was designed for an extremely limited environment (for example, single-character variable names). What most people think of as BASIC was the Microsoft Visual Basic [TM], which is considerably different.
Note the word "Microsoft". That was its boon and its bane. Microsoft owned it - and its successort, VB.Net, and only systems with Microsoft's blessing ever got it. The Amiga got a variant of it, I think some Mac systems got one, but Linux never did as far as I know. Linux had to make do with Python.
Python has become to Linux - and by extension, the current MacOS and BSD platforms - what VB was to Windows. It would certainly make a good hyperscripting language, and it's not at the mercy of a single vendor.
The Amiga had some serious flaws. I had 3 of them as well, as Macs, Apple IIs and PCs. No memory protection so badly behaved programs could bring down the system and an OS hardwired to custom hardware which made it difficult to impossible to progress going forward. Plus, I personally, found the UI to be wretched. I did have a lot of fun on it though.
Actually, none of the popular OS's of the day had memory protection. But they were all either mono-tasking or had some sort of arcane co-operative multi-tasking that required careful programming. The Amiga was designed so that even the simplest sloppiest "hello world" program was running under multi-tasking, but the base-level hardware (Motorola MC68000) had no integral memory management unit. The later models, based on the 68020 and 68030 could have had memory management, but Commodore wasn't capable of the necessary forking of the OS.
The custom hardware was fronted by APIs expressly designed so that people who followed the Amiga developer's guidelines would be isolated from hardware dependencies and hardware improvement. Which isn't to say that a lot of people didn't out-clever it, but no OS is immune from clever-itis.
A friend of mine said the Amiga UI looked like it was done with crayon, and he's probably right. On the other hand, the thing I miss most about the Amiga is that it was smart enough to hide the mouse pointer when you started typing near it (so the pointer wouldn't hide text being typed), and the alert dialog boxes didn't steal the input focus. I cannot begin to count how many times something horrible has happened on other systems when I was typing in a text window, a dialog popped up and considered my "end-of-line" to think I had just hit "Yes" on an "OK to reformat disk?"-type dialog.
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
The problem here is that in complex production environments, servers are not atomic units. Obviously, if the network is down, apache cannot run, but just because the LDAP server is out of commission, that doesn't mean that webapps that don't use LDAP cannot continue to run.
That's the potential of systemd. To ensure that a process that cannot operate except when other processes that is depends on are OK. '
Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.
Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.
Autopilots on production servers seem like a bad idea to me.
In larger shops, uptime, even with warts is preferable to downtime. If a service goes offline, they want it online ASAP and you can do the post-mortem at your leisure (just don't expect to be allowed any leisure - those executive bonuses got to come from somewhere). Furthermore, as I mentioned, systems are often a network of processes, not just a single process, so having one process go down may require taking dependent processes offline. Conversely, when a subsystem comes back up, it's better that the dependents automatically follow it back up rather than requiring you to chase around and restart them all manually. That's where sooner or later, one of the restarts gets missed. Until someone important misses it.
OK. I've said something in favor of "systemd". The problem is, systemd isn't really one conceptual product, it's systemctl and journalctl. Systemctl I'm OK with. Journalctl can die in fire. Any votes in favor of "systemd" on behalf of systemctl should NOT be considered as endorsement for journalctl.
A reasonable complaint. Participation in making it better is way better than just bellyaching. I suggest you file a bug and help shape journalctl to what you think it should be based on your experience. They do need that kind of feedback.
If I thought it would do any good. Needing feedback isn't the same as accepting it.
I have, in a long and evil career, encountered all sorts of development groups. Some were very friendly and open to suggestion. The Commodore Amiga team, Objectweb's JOnAS group. More commonly, there are groups who'll either ignore suggestions, or get outright hostile at the mere thought that anyone could be so uncultured and stupid as to not realize that they'd done everything Exactly Perfect and if there was a problem, it was a personal deficiency on the part of the consumer.
Filing a bug report on such projects is an exercise in futility. The best you can do is make a lot of noise in public spaces and hope that enough other people do too that either some other group feels motivated to find a better solution or that the original group realizes that they're never going to get any love and becomes more accomodating.
In fact, a spinning sulfur ball and a silk brush could probably generate enough current at high voltage to do the trick.
You're hired!
Actually, current doesn't matter as much as voltage, but if crude spark technology is all you want, I'd say you've got it down.
I had a "radio set" that consisted of an unplugged transistor amplifier, a speaker, and the wire running from the speaker to the amp. Because I lived across the street from a 5KW AM radio transmitter, it would whisper eerily in the dark. The final-stage transistors replaced the galena rectifier/demodulator, the speaker wire served as antenna and the speaker served as... well, what do you think?
A friend had me beat though. Across the street from him was a 100KW FM transmitter. He said the light bulb in his medicine cabinet used to sing to him.
I have the Foxfire books. So I have old-time know-how at my disposal. Although I'm going to have to turn vegetarian when it comes to the hog-slaughtering part, bacon or no bacon. I've been doing a kitchen garden for years, though, and it's now quite obvious why certain foods and spices are stereotypical to the region!
If it wasn't booting, then there is some sort of error message. Or no error message just a hang maybe! But no, that's never what anyone feels is "worth" mentioning. Just "it broke". I'm sure in debugging init script problems they would've supplied exactly the same information. Or you know, not, because it's extremely unlikely their system was locking up completely.
OK. I'll tell you what it did to me. Completely hung the booting process. Was some sort of filesystem error that would have simply blipped by on sysV and been fixable after booting. And, for that matter, it likely got logged. IN A BINARY LOG. THAT REQUIRED A BOOTED COMPATIBLE OS TO READ.
Mind you, I like the concept of systemctl. I just think it needs polish. It's journalctl that I loathe with every fiber of my being because I learned to despise binary logs when I was inflicted with mainframes and OS/2. The only reason I don't loathe the Windows Event Recorder is probably because I don't do the free-form log search and manipulation functions that I do in Linux when I'm running Windows.
I don't want an extra program injected into my log analysis functions.
I don't want to have to be restricted to only being able to interpret logs if they are on or can be transported to a functioning system with similar log tools.
I don't want to wake up one day and discover that critical logs can no longer be read because the binary file format specification has changed and I don't have a compatible decoding program.
I don't want the logs for everything to be all lumped together the way that unrelated application options are lumped together in the Windows Registry. There's a time and a place for consolidated log files - even binary ones - just not in my critical daily operations.
In short, I DO NOT WANT JOURNALCTL.
I'm not saying this because I don't like the concept. I'm saying it because I've already had it pushed on me and I don't like the practice.
Slashdot Mirror
The whole premise of the Foundation series is obsolete. The premise was that it was possible to predict the future to a moderate level of detail by calculation. Now that vast efforts have been expended in that direction by the weather and financial communities, we have a reasonably clear understanding of what can and cannot be accomplished in the prediction department. We know now that little changes grow into big ones (the "butterfly effect") rather than being filtered out. The future is driven by unpredictable noise.
Hardly obsolete. Validated, if anything. The modern-day psychomathematics is just Big Data and statistical analysis rules. The book gets thicker every day, and the NSA is based on it. So is corporate marketing.
Asimov also realized that a butterfly could run the train off the rails, which is why Seldon didn't merely work out the mathematics and turn it all loose. The Second Foundation existed precisely to apply compensating forces and to re-calculate the math as time unfolded.
... if not decades later often with an entirely different cast of characters.
Not infrequently a century or more, IIRC. The Foundations were supposed to collapse the interregnum down to a mere millenium or so.
I Robot had nothing to do with the book. It was in fact written on another title first and then they bought the name to slap on it because people would recognize it, and, hey, it's about robots, right? A bit of script touch-up to change a few names (gotta have Susan Calvin, although of course she won't be plain) and put in a few references to Asimov's concepts, and we're done!
I love Will Smith, and the movie was quite the spectacular, but Asimov would have had an aneurysm.
Asimov was actually more of a mystery writer than a straight-up SF author. He wrote straight mystery novels, too, but then he wrote something for every aisle of the Dewey Decimal System. The robot stories are almost all mysteries, and quite a few of them were murder mysteries, where a robot was apparently at fault despite the Three Laws. The riddle was how to explain what happened without violating those laws.
The movie said "screw it - the robot dunnit" and thereby took the easy way out.
It might have been forgivable if the lessons of that story were what caused the formulation of the 3 laws - I Robot, II. But no such implication was made that I saw. And regardless, it was still taking the easy way out.
Asimov could have managed to cause Calvin to envisage the 3 laws and STILL let the robot off the hook.
Asimov never aspired to be Science Fiction's God of Sex - he left that for Heinlein. But the only reason that the original foundation was so tame was because no one had sex back then.
He wrote very differently once the 1970's rolled in and had some very outspoken views on sex, the evolution of marriage, and other consequences of the century's improvements in lifespan, birth and disease control.
Foundation was not really prudish, but Asimov really didn't include (any that I recall) blatant sex scenes or sexual themes in his books, at least directly.
Well fush!
After all, like he said, "IT doesn't matter".
It's true, though. IDEs full of wizards and other magic make it look like less-capable (cheaper) people can do software. So that's what management hires.
Problem is, the IDEs can make a capable developer's job easier, but an incapable developer becomes utterly lost when the IDE falls short or breaks down.
It has two completely opposite meanings:
Yeah, yeah.
All you have to do is add 36-0-0 nitrate fertilizer to it and you've got one high-explosive fire bomb. Easy lethal weapon.
With gasoline you don't even need the fertilizer.
Gasoline is more volatile but even it doesn't explode when you touch a match to it.
That's why internal combustion engines have carburators or similar vaporization systems.
Imagine every battery replaced by a canister of jet fuel. It would be the Petroleum Industry's dream.
Imagine every battery replaced by a canister of jet fuel. It would be the Terrorist Industry's dream.
Forget Lethal Weapon. Jet fuel is basically kerosene. You can't just touch a match to it and it explodes.
Actually, some batteries are more explosive than an equivalent (shall we say 3oz.?) sized canister of jet fuel.
but once you fail the drug test for traces opiates you are guilty until proven innocent
No, in post 1980s America, you are guilty of lots of things until you prove yourself innocent. And not "once you fail the drug test", because the test was given under the presumption you're guilty to begin with. Is testing for explosives residues on your hands a pre-condition for employment? Not yet, anyway.
Before Reagan promised to "get the government off the backs of the people", you didn't routinely find employers requiring drug tests. Nor did you have to prove up front that you weren't an illegal alien. Which, incidentally, doesn't seem to have done much from keeping employers from actually hiring illegal aliens.
But there you have it. If you were born after 1980, you've been a presumed criminal all your life.
You know what amuses me about all this systemd hate.
Fedora was the first distro to go systemd by default back in F15. There were a few growing pains, but there wasn't the coordinated systemd hatred until pretty much recently when RHEL7 went out the door and debian said we're going systemd.
Well, some of it was simply that I had better things to do with my time than upgrade Fedora.
When I did, that's when I encountered systemd.
Our basic premise is that the current "industrial" model of IT hiring/management -- treating IT engineers like cogs or components -- is fundamentally flawed, and that a model based on professional sports teams would likely work much better.
That's nice. Let me know when you start getting a large number of companies agreeing with you. Part of the whole "keeping down the rank and file" in the wage category is making them believe they are easily replaceable cogs.
AH yes, but the Libertarian approach says that you stand up and tell them that you are not. That you have a proven record of excellence. And that you'll refuse to accept their puny offerings. Which, in the spirit of true market arbitration will cause them to reconsider.
(cue laughter)
The professional sports model isn't always the best. Ever heard of the Chicago Cubs and their 100+ years of futility?
You seem to have confused not winning games for not making their owners more money than any other team out there.
The Cubs exist primarily to provide satisfaction for people who think that life is a losing game.
If they ever went to the Series, it would be pandemonium.
Like hiring sports teams in what sense? Like the NFL draft? Big companies get to pick who they want from each year's graduating class, with little if any choice on the part of the new-minted engineers, and most of the graduates don't ever get to use their skills professionally?
When we hire we look for specific skills that are relevant to our business. Maybe that's what you mean. We try to be careful about what's an absolute must (e.g. knows C++) and make the rest of the qualifications "preferred" or "desired." We rarely get an exact match between what we'd like to have and the candidate but that's OK. We hire people that can learn.
The All-American institution NFL is rather socialist, actually. Unlike pro baseball, the richest team doesn't get all the marbles, because of salary caps and the draft ordering process that says that the teams with the worst previous-season record get preferred picks. There's a also a quite respectable minimum salary just for being on the team at all.
Baseball comes in tiers. If you don't make the majors, you still might find something on one of the farm team levels, You earn progressively less as you go down, but then we like to claim the USA is a meritocracy.
And yes, we all know that there are some people who deserve to wash out. People are not all equally suited and it's better for the marginal cases to look for something they'd be better at.
Seriously. The whole concept of business organization is stuck in the factory mentality of 200 years ago. People aren't interchangeable cogs and business needs to stop considering them as such. Cogs don't care about the business any more than business cares about the individual cogs.
Sports teams aren't the only alternative model that could be considered - after all Fred Brooks suggested a surgical team organization back in the 1960s. But the world is on the brink of major changes and we need to consider all the possibilities we can.
My personal favorite - and one I was dinged on several times before I learned to basically just lie my ass off about it - was how many servers I've been responsible for at one time. At some ISP jobs I've had, I've had to touch hundreds of unique servers while helping clients, but only had maybe 20-30 to worry about day to day. But companies hiring based on this metric want to hear that you were administering 200+, 500+, whatever number of servers on a daily basis. This is bullshit for two main reasons:
1. No single person is personally touching dozens or hundreds of servers on a daily or even weekly basis. A _team_ of people might, but a person isn't.
My take on this is that if there are 200+ servers, any on of which you may be required to service, the fact that you don't "touch" them all daily doesn't matter and that there's no lie involved here.
That's like rating the fire department on the number of houses they visit instead of the number of houses they protect.
The more servers you have to touch on a daily basis, the more likely that they're not well-configured.
This.
Let the market decide. If DRM angers you, don't buy games from companies that use DRM.
The issue with the Religion of the Market is that it's really quite incredible the amount of abuse that people will accept when there's only one source for a product. Or, for that matter, just to get the Low Price Always.
I'd vote for quality of life myself, but the Market is against me.
No, the 68000 had no MMU. All the Sun/Apollo machines I knew of had 68020's in them, which do have MMUs.
Motoroloa made the MC68851 as an external MMU device, which could be paired with the 68000, but the Amiga didn't incorporate it.
BASIC had its day. The original BASIC was designed for an extremely limited environment (for example, single-character variable names). What most people think of as BASIC was the Microsoft Visual Basic [TM], which is considerably different.
Note the word "Microsoft". That was its boon and its bane. Microsoft owned it - and its successort, VB.Net, and only systems with Microsoft's blessing ever got it. The Amiga got a variant of it, I think some Mac systems got one, but Linux never did as far as I know. Linux had to make do with Python.
Python has become to Linux - and by extension, the current MacOS and BSD platforms - what VB was to Windows. It would certainly make a good hyperscripting language, and it's not at the mercy of a single vendor.
The Amiga had some serious flaws. I had 3 of them as well, as Macs, Apple IIs and PCs. No memory protection so badly behaved programs could bring down the system and an OS hardwired to custom hardware which made it difficult to impossible to progress going forward. Plus, I personally, found the UI to be wretched. I did have a lot of fun on it though.
Actually, none of the popular OS's of the day had memory protection. But they were all either mono-tasking or had some sort of arcane co-operative multi-tasking that required careful programming. The Amiga was designed so that even the simplest sloppiest "hello world" program was running under multi-tasking, but the base-level hardware (Motorola MC68000) had no integral memory management unit. The later models, based on the 68020 and 68030 could have had memory management, but Commodore wasn't capable of the necessary forking of the OS.
The custom hardware was fronted by APIs expressly designed so that people who followed the Amiga developer's guidelines would be isolated from hardware dependencies and hardware improvement. Which isn't to say that a lot of people didn't out-clever it, but no OS is immune from clever-itis.
A friend of mine said the Amiga UI looked like it was done with crayon, and he's probably right. On the other hand, the thing I miss most about the Amiga is that it was smart enough to hide the mouse pointer when you started typing near it (so the pointer wouldn't hide text being typed), and the alert dialog boxes didn't steal the input focus. I cannot begin to count how many times something horrible has happened on other systems when I was typing in a text window, a dialog popped up and considered my "end-of-line" to think I had just hit "Yes" on an "OK to reformat disk?"-type dialog.
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
The problem here is that in complex production environments, servers are not atomic units. Obviously, if the network is down, apache cannot run, but just because the LDAP server is out of commission, that doesn't mean that webapps that don't use LDAP cannot continue to run.
That's the potential of systemd. To ensure that a process that cannot operate except when other processes that is depends on are OK.
'
Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.
Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.
Autopilots on production servers seem like a bad idea to me.
In larger shops, uptime, even with warts is preferable to downtime. If a service goes offline, they want it online ASAP and you can do the post-mortem at your leisure (just don't expect to be allowed any leisure - those executive bonuses got to come from somewhere). Furthermore, as I mentioned, systems are often a network of processes, not just a single process, so having one process go down may require taking dependent processes offline. Conversely, when a subsystem comes back up, it's better that the dependents automatically follow it back up rather than requiring you to chase around and restart them all manually. That's where sooner or later, one of the restarts gets missed. Until someone important misses it.
OK. I've said something in favor of "systemd". The problem is, systemd isn't really one conceptual product, it's systemctl and journalctl. Systemctl I'm OK with. Journalctl can die in fire. Any votes in favor of "systemd" on behalf of systemctl should NOT be considered as endorsement for journalctl.
I saw the picture of the plain with the patch on it. Apparently the patch was used to cover up what had been an observation window.
Aluminum doesn't discolor much, but the fingerprint wasn't color, it was the rivet pattern.
A reasonable complaint. Participation in making it better is way better than just bellyaching. I suggest you file a bug and help shape journalctl to what you think it should be based on your experience. They do need that kind of feedback.
If I thought it would do any good. Needing feedback isn't the same as accepting it.
I have, in a long and evil career, encountered all sorts of development groups. Some were very friendly and open to suggestion. The Commodore Amiga team, Objectweb's JOnAS group. More commonly, there are groups who'll either ignore suggestions, or get outright hostile at the mere thought that anyone could be so uncultured and stupid as to not realize that they'd done everything Exactly Perfect and if there was a problem, it was a personal deficiency on the part of the consumer.
Filing a bug report on such projects is an exercise in futility. The best you can do is make a lot of noise in public spaces and hope that enough other people do too that either some other group feels motivated to find a better solution or that the original group realizes that they're never going to get any love and becomes more accomodating.
In fact, a spinning sulfur ball and a silk brush could probably generate enough current at high voltage to do the trick.
You're hired!
Actually, current doesn't matter as much as voltage, but if crude spark technology is all you want, I'd say you've got it down.
I had a "radio set" that consisted of an unplugged transistor amplifier, a speaker, and the wire running from the speaker to the amp. Because I lived across the street from a 5KW AM radio transmitter, it would whisper eerily in the dark. The final-stage transistors replaced the galena rectifier/demodulator, the speaker wire served as antenna and the speaker served as... well, what do you think?
A friend had me beat though. Across the street from him was a 100KW FM transmitter. He said the light bulb in his medicine cabinet used to sing to him.
I have the Foxfire books. So I have old-time know-how at my disposal. Although I'm going to have to turn vegetarian when it comes to the hog-slaughtering part, bacon or no bacon. I've been doing a kitchen garden for years, though, and it's now quite obvious why certain foods and spices are stereotypical to the region!
If it wasn't booting, then there is some sort of error message. Or no error message just a hang maybe! But no, that's never what anyone feels is "worth" mentioning. Just "it broke". I'm sure in debugging init script problems they would've supplied exactly the same information. Or you know, not, because it's extremely unlikely their system was locking up completely.
OK. I'll tell you what it did to me. Completely hung the booting process. Was some sort of filesystem error that would have simply blipped by on sysV and been fixable after booting. And, for that matter, it likely got logged. IN A BINARY LOG. THAT REQUIRED A BOOTED COMPATIBLE OS TO READ.
Mind you, I like the concept of systemctl. I just think it needs polish. It's journalctl that I loathe with every fiber of my being because I learned to despise binary logs when I was inflicted with mainframes and OS/2. The only reason I don't loathe the Windows Event Recorder is probably because I don't do the free-form log search and manipulation functions that I do in Linux when I'm running Windows.
I don't want an extra program injected into my log analysis functions.
I don't want to have to be restricted to only being able to interpret logs if they are on or can be transported to a functioning system with similar log tools.
I don't want to wake up one day and discover that critical logs can no longer be read because the binary file format specification has changed and I don't have a compatible decoding program.
I don't want the logs for everything to be all lumped together the way that unrelated application options are lumped together in the Windows Registry. There's a time and a place for consolidated log files - even binary ones - just not in my critical daily operations.
In short, I DO NOT WANT JOURNALCTL.
I'm not saying this because I don't like the concept. I'm saying it because I've already had it pushed on me and I don't like the practice.
SysAdmin !== Programmer
No, that was the 20th Century. We're now Lean. So SysAdmin == Programmer == DBA == Network Administrator == Janitor