Netflix has a $70B market cap and they run in AWS and have no intention whatsoever to go back to traditional data centers. Running them well is hard and hiring competent people to run them is even harder: Amazon, Google, Facebook and Microsoft hired a good chunk of the talent. Zinga tried AWS, found it expensive so went back to traditional Datacneveral migrations to AWS and the dumb companies do it without chewing their software architecture.
Newsflash, AWS is expensive if you do not rewrite your code for auto scaling and Setup your QA/Dev environments to be 'on demand'. But as far as uptime is concerned, you cannot beat Amazon uptime if you have built multi-region deployments. If you use it like a traditional data center, well shit happens and Amazon machines die like any other. Their SLAs actually guarantee nothing about individual hosts.
That's horsecrap, and the "everyone else is wrong so use our new paradigm to overlook our problems" attitude is exactly what's wrong with it.
If you're making consumer-level applications that don't need data integrity then it might be "good enough". If you need enterprise reliability, it's absolutely not "good enough" without a lot more engineering.
There are plenty of competent datacenter operations folks, and running one is NOT rocket science, it just requires awareness of reliability engineering and infrastructure/operational experience. In exchange, you have actual control and actual responsibility for your mission-critical infrastructure.
A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result.
In other words, nobody can think of anything better, and would just rewrite SystemD?
There are legitimate criticisms about code quality and -- certainly -- project design, management, and organization within systemd, but there are others that object philosophically to the systemd paradigm to begin with.
There may be benefits to rewriting systemd, but I count myself among the latter. IMO, the init system (and other building blocks needed to boot the system to or past the equivalent of a single-user mode) should be fundamentally distinct from service management. Hence my comment above -- systemd would be fine if it was a replacement for xinetd, or an option like daemontools, hanging off of the existing imperative init system.
Systemd is a modular architecture with many small pieces plugged together.
It may theoretically be a modular architecture, but it forces an entirely novel paradigm on the system... and it did so through strong-arm tactics. A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result. Welcome to complexity lock-in that no one asked for.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever.
If you do not know how to shell script, you have no business administering a server (ie, being a sysadmin) in a real-world environment. systemd may be fine for end-user graphical boot desktop environments (launchd works great for OS X), but this experience is from systems engineering and administration's perspective.
There are plenty of reasons why having logic over a config file is a tenable position. It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it. Config files are not a net win, and the win they do give you (boilerplating the most simple initscript cases) could easily be achieved a different way (like variables sent to a shell script that executes library code, a la/etc/init.d/functions.
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.
Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.
Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Developers use Ubuntu; server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases now have an option.
What I'd really love is a Fedora fork (or EL clone, such as Scientific Linux) that reverts to the EL6 initscript build-out and considers systemd as just another option to be used on top of a standard SysV base -- much like xinetd. There if you need it, but not affecting the core.
"There are web apps that work in Chrome but not really all that well elsewhere."
10-15 years ago, there were "web apps" that worked in Internet Explorer but not really at all well elsewhere.
Google decided, a couple years ago, to basically go that same route... and probably for the same reasons. It's all about lock-in.
Agreed with lock-in, but what Google is doing is quite different from the Microsoft days.
Microsoft wanted IE-first support and was battling with Netscape, but didn't have a specific internet tie for the data being transmitted because it was an OS and apps company, not an internet company.
Google controls 75% of all advertising, half of all smartphones' entire software stacks, and is more than willing to track everything you do, and in fact send all of your web requests out through Google's own servers. "Browser lock-in" takes on an entirely different meaning in today's world.
Humor aside, the lack of ability to reproduce experiments doesn't necessarily make a field of study more or less scientific. After all, you could include astronomy and climate science among those, at least to some degree.
Yes, this is EXACTLY the case. Cosmology is a very interesting field of study, but it's not science. Things that are irreproduceable via experiment are, for all intents and purposes, not "sciences". They might be very cool and intruiging areas of research and study, but that doesn't make them sciences.
"Climate science" is not science unless you have a spare Earth in your back pocket somewhere you can use as a control group for your experiments. Various things that "climate science" might use in coming to conclusions about something might involve science (eg, molecular physics), but the field as a whole is not.
Did Poettering go over there? If not, can we send him there? And try to undo some of completely broken scheisse that has infected our Linux distributions in the last 4-6 years or so? All you GNOME developers trying to re-create a commercial desktop OS can keep your toys over there, while those of us who need deterministic, predictable server OS's can fix this mess ourselves. Thanks.
How about you just fork off one of the older branches of Android (2.x?), fix all the security holes you've refused to backport because Google is filled with engineers who look at reliability engineering entirely the wrong way, add the bare minimum features needed for future compatibility (TLS, etc) or that are no-brainer efficiency improvements, and then offer that as a stable branch.
On workstations, attackers can access mpengine by sending emails to users (reading the email or opening attachments is not necessary), visiting links in a web browser, instant messaging and so on. This level of accessibility is possible because MsMpEng uses a filesystem minifilter to intercept and inspect all system filesystem activity, so writing controlled contents to anywhere on disk (e.g. caches, temporary internet files, downloads (even unconfirmed downloads), attachments, etc) is enough to access functionality in mpengine. MIME types and file extensions are not relevant to this vulnerability, as MsMpEng uses it's own content identification system.
Vulnerabilities in MsMpEng are among the most severe possible in Windows, due to the privilege, accessibility, and ubiquity of the service.
The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers and cryptors, full system emulators and interpreters for various architectures and languages, and so on. All of this code is accessible to remote attackers.
tl;dr: The Javascript engine in Windows Defender (which tries to figure out if it's a virus) has a flaw. Exploit works and can be leveraged if you can force the victim to write something to disk (triggering a scan): eg, sending an email, viewing an image, writing a log entry, etc.
Not a Windows Update, the fix is coming as part of the Windows Defender definitions updates rollout process.
That's basically where I'm at with it. I was familiar with Slackware's init, I was familiar with Debian's init. Can't remember off of the top of my head but I believe one used SysV, the other used BSD. Either way, not that complicated, easily fixed by hand if necessary.
If a replacement for the various fragmented inits was limited in its scope then I would be fine with such a replacement. Trouble is, this seems to have taken the kitchen-sink approach, throwing everything in whether it's needed or not, and worse, it seems to have broken the tenet that everything is editable with a text editor and some patience.
Yeah. There's very little in the "replace with config" space that couldn't already have been accomplished with other tools, or by writing their own. That's essentially what you already have with superservers like xinetd or even DJB's daemontools, which can successfully be hung off the edge of an otherwise opaque rest-of-the-init-system. Most importantly, that provides ISOLATION and a defined interface without demanding changes everywhere else.
If someone wanted a new fancy parallel superserver for socket systems, that's fine. If some of "/etc/rc" and "/etc/rc.sysinit" (in RH-land) was to be optimized or rejiggered or (heaven forbid) replaced with a busybox-like super binary that does a bunch of stuff, fine. But those two things are orthogonal and should have been treated as separate projects.
The ironic thing is that a big chunk of what systemd was originally sold as ("Faster boot speeds!") was achievable with what should have been a third project in RH-land: Following Debian in changing/bin/sh to dash instead of bash.
Yep. The problem isn't that the government isn't "digital" enough, the problem is that it's run by people who wouldn't recognize the scientific method if it was served to them on a plate with a sprig of parsley on top.
If he goes to Silicon Valley all he'll find is a bunch of people who want to sell him a lot of useless new computers+software under a lucrative government contract.
If he goes to Silicon Valley all he'll find is a bunch of people who fetishize 'data' and algorithmic analysis over critical thinking, reasoning, reliability engineering, or domain knowledge skills. We tried this in 2008 and a bunch of the data experts failed then too, because this shit is actually hard and usually doesn't get solved by the creative destruction of a new image recognition app to replace bureaucrats.
Face it, they both suck balls, you are just more familiar with a particular ball sucker.
No. People writing shell scripts that don't know how to suck balls.
Init scripts aren't complicated, but different Unices (even within the SysV tradition) have solved various problems different ways. Beyond lack of shell knowledge, most of the really horribly written init scripts I've seen as an RH admin have been from Debian-focused writers who aren't familiar with RH conventions. RH makes stuff super easy with/etc/init.d/functions to do most of what you need. And most stuff that isn't included is dealing with some weird issue with the daemon you're starting to begin with.
Admittedly, maybe that lack of cross-distro drop-and-replace was a reason to standardize on something, but that's kind of what LSB guidelines were there for. We didn't need systemd, let alone allllllll the other shit that systemd forced down our throats in its Giant Leap Forward.
Even more lamentably there are reports that systemd is causing intentional incompatibilities. This isn't just a repeat of information that isn't as good as second-hand, so don't take it seriously, but merely as something to watch for.
I suspected/expected that would occur. Any pointers to background there?
The site was destroyed in some construction project. Before 1995.
There will be no new samples from this site ever. The site does not exist any more. That is why the field is called "salvage" archaeology. Whatever you get (including records) is all there will ever be.
Well, maybe. The freeway berm hadn't been completely uncovered before the main part of the freeway needed to go in.
More to the point: Have you ever been to San Diego? We have huge canyons, valleys, and hills all over the place even just within the official city (proper) limits. I guarantee with more ground penetrating radar or other scanning techniques there are other samples waiting to be found.
Sure working outdoors will make you lose some salt through sweat, but unless you're crossing a desert on hard rations that's doing you more good than harm.
More than that. If you're working all day in the hot sun and only drinking water, you're at real danger of heat cramps, followed by heat exhaustion and something worse.
You don't need *much* salt, but if you're sweating all day you need SOME. Gatorade or another electrolyte solution is carried on ambulance rigs in hotter areas for just this purpose.
Once a phone call is initiated it poses little or no risk as it continues. If I start a phone call while I'm at a stop light and continue with it I'm really not posing any additional danger to anyone. By comparison taking your eyes off the road to read and write a text message is inherently dangerous any time you are attempting to drive while doing so.
Ironically, the initial justification for cell phone bans (before the era of smartphones) was the exact opposite. Cell phones with physical buttons were easy to dial with, could be done by touch many times, and scrolling a linear list of contacts was easy. The "concern" was that an emotional call (or any call at all) would be distracting in a way that listening to the radio wasn't. This is why other "fiddling with things" tech, even available then, wasn't included in the ban here in CA. (I'm talking about things like dedicated GPS receivers, and classic iPods.)
Text messaging alone didn't seem to really take off until the early-mid 2000s in the US outside of certain circles.
Nowadays, of course, it's almost completely the opposite. Phone calls are rarer, and your mobile device is multifunction and used for all sorts of things by the broad populace on a regular basis.
I have to generally agree with the grandparent/first post though. If EVERYONE is doing it regardless, the draconian law should be changed so something more meaningful and fairer to enforce. I'd say more people are breaking the cell phone law than are breaking speed limits -- and that's something. In CA you're not allowed to have your cell in hand even stopped at a traffic light which (as annoying as it is to have to honk at someone that the light's changed) not as much harm as that ticket would seem to imply.
My suggestion: "special circumstances" for injury accidents and reckless driving / moving violation crimes with hands off the wheel and a renewed emphasis on "Don't do distracted driving" vs "Don't look at your cell phone". Let's be realistic, and we'll have much more compliance.
Congratulations, folks... BK has successfully demonstrated a giant vulnerability in Google's (and Amazon's, and Apple's...) product - it responds to voices from people it doesn't know, and the default access phrase is well-known.
Maybe instead of whining about Burger King, you can pressure your vendor to fix their design flaws. Or better yet, disable all voice recognition/spying devices and banish them from your house completely.
Just a few examples, but beyond the google I'm especially aware of Amazon, Apple, Microsoft, and Exxon. Feel free to add your favorite corporate cancer here.
Exxon? Really? That's fairly retro. Ranting about Standard Oil and, to some extent, Baby Bells that aren't directly involved in cell tracking, seems rather quaint.
Replace Exxon with Facebook and you've got a far stronger argument. Exxon can charge me for oil and oil products. Facebook has enough privileges on any given smartphone to track me 24 hours a day and manipulate my interaction with most of my friends (while Google controls my interaction with rest of the world).
"We aren't dealing with ordinary machines here. These are highly complicated pieces of equipment. Almost as complicated as living organisms. In some cases, they have been designed by other computers. We don't know exactly how they work."
^ Mod parent up. That's entirely the issue. It's like he's intentionally designing something *MORE* complex but slightly more efficient in the hopes that it'll be a justification to get the humans out of the loop entirely.
Interestingly enough, some of the posts I see on Facebook claim that the investment in robots and AI is happening because of the increase in the minimum wage...and something, something illegal aliens. I hate my Facebook feed.
The operative word is "because". It was already going to happen due to the laws of economics, but if it happens gradually enough there's a much higher chance of society successfully adapting and digesting the changes through longer-term programs.
Raise the minimum wage too quickly too high ($15 in Podunk, USA), vastly increase costs for employing people (30hr/week = health insurance), and you shock the system, forcing an earlier-than-expected look at capital investment.
Add in a Silicon Valley that's oblivious to any problems outside of the liberal, progressive, Bay Area bubble they live in, with priorities completely out of whack with the real world so long as the IPO money keeps flowing in, creating automation and tech simply because "they can now" and with an undying, almost religious belief in the merits of technocratic efficiency (like good little central planners), and you have a perfect storm of circumstances for mass layoffs and accelerating automation.
Without the ability to digest these changes, either the tech oligopoly gets nuked, mass revolution occurs (of which Trump might be the precursor), or we'll continue spiraling downward until the technological singularity hits... at which point all bets are off.
Slashdot Mirror
Netflix has a $70B market cap and they run in AWS and have no intention whatsoever to go back to traditional data centers. Running them well is hard and hiring competent people to run them is even harder: Amazon, Google, Facebook and Microsoft hired a good chunk of the talent. Zinga tried AWS, found it expensive so went back to traditional Datacneveral migrations to AWS and the dumb companies do it without chewing their software architecture.
Newsflash, AWS is expensive if you do not rewrite your code for auto scaling and Setup your QA/Dev environments to be 'on demand'. But as far as uptime is concerned, you cannot beat Amazon uptime if you have built multi-region deployments. If you use it like a traditional data center, well shit happens and Amazon machines die like any other. Their SLAs actually guarantee nothing about individual hosts.
That's horsecrap, and the "everyone else is wrong so use our new paradigm to overlook our problems" attitude is exactly what's wrong with it.
If you're making consumer-level applications that don't need data integrity then it might be "good enough". If you need enterprise reliability, it's absolutely not "good enough" without a lot more engineering.
There are plenty of competent datacenter operations folks, and running one is NOT rocket science, it just requires awareness of reliability engineering and infrastructure/operational experience. In exchange, you have actual control and actual responsibility for your mission-critical infrastructure.
You know, just like how we used to do it.
A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result.
In other words, nobody can think of anything better, and would just rewrite SystemD?
There are legitimate criticisms about code quality and -- certainly -- project design, management, and organization within systemd, but there are others that object philosophically to the systemd paradigm to begin with.
There may be benefits to rewriting systemd, but I count myself among the latter. IMO, the init system (and other building blocks needed to boot the system to or past the equivalent of a single-user mode) should be fundamentally distinct from service management. Hence my comment above -- systemd would be fine if it was a replacement for xinetd, or an option like daemontools, hanging off of the existing imperative init system.
Systemd is a modular architecture with many small pieces plugged together.
It may theoretically be a modular architecture, but it forces an entirely novel paradigm on the system... and it did so through strong-arm tactics. A replacement for systemd that doesn't end up just reverting back to SysV will have to end up looking a lot like systemd as a result. Welcome to complexity lock-in that no one asked for.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever.
If you do not know how to shell script, you have no business administering a server (ie, being a sysadmin) in a real-world environment. systemd may be fine for end-user graphical boot desktop environments (launchd works great for OS X), but this experience is from systems engineering and administration's perspective.
There are plenty of reasons why having logic over a config file is a tenable position. It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it. Config files are not a net win, and the win they do give you (boilerplating the most simple initscript cases) could easily be achieved a different way (like variables sent to a shell script that executes library code, a la /etc/init.d/functions.
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.
Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.
Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Developers use Ubuntu; server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases now have an option.
What I'd really love is a Fedora fork (or EL clone, such as Scientific Linux) that reverts to the EL6 initscript build-out and considers systemd as just another option to be used on top of a standard SysV base -- much like xinetd. There if you need it, but not affecting the core.
"There are web apps that work in Chrome but not really all that well elsewhere."
10-15 years ago, there were "web apps" that worked in Internet Explorer but not really at all well elsewhere.
Google decided, a couple years ago, to basically go that same route... and probably for the same reasons. It's all about lock-in.
Agreed with lock-in, but what Google is doing is quite different from the Microsoft days.
Microsoft wanted IE-first support and was battling with Netscape, but didn't have a specific internet tie for the data being transmitted because it was an OS and apps company, not an internet company.
Google controls 75% of all advertising, half of all smartphones' entire software stacks, and is more than willing to track everything you do, and in fact send all of your web requests out through Google's own servers. "Browser lock-in" takes on an entirely different meaning in today's world.
Also don't forget quantum mechanics. Everything that is below electrons and protons isn't even directly observable.
That's exactly why string theorists get askance glances from other physicists. Also apropos: https://xkcd.com/397/
Humor aside, the lack of ability to reproduce experiments doesn't necessarily make a field of study more or less scientific. After all, you could include astronomy and climate science among those, at least to some degree.
Yes, this is EXACTLY the case. Cosmology is a very interesting field of study, but it's not science. Things that are irreproduceable via experiment are, for all intents and purposes, not "sciences". They might be very cool and intruiging areas of research and study, but that doesn't make them sciences.
"Climate science" is not science unless you have a spare Earth in your back pocket somewhere you can use as a control group for your experiments. Various things that "climate science" might use in coming to conclusions about something might involve science (eg, molecular physics), but the field as a whole is not.
Did Poettering go over there? If not, can we send him there? And try to undo some of completely broken scheisse that has infected our Linux distributions in the last 4-6 years or so? All you GNOME developers trying to re-create a commercial desktop OS can keep your toys over there, while those of us who need deterministic, predictable server OS's can fix this mess ourselves. Thanks.
How about you just fork off one of the older branches of Android (2.x?), fix all the security holes you've refused to backport because Google is filled with engineers who look at reliability engineering entirely the wrong way, add the bare minimum features needed for future compatibility (TLS, etc) or that are no-brainer efficiency improvements, and then offer that as a stable branch.
Or am I missing the point?
#FeatureBloatSucks
Official announcement: https://technet.microsoft.com/en-us/library/security/4022344
More background / report: https://bugs.chromium.org/p/project-zero/issues/detail?id=1252&desc=5
tl;dr: The Javascript engine in Windows Defender (which tries to figure out if it's a virus) has a flaw. Exploit works and can be leveraged if you can force the victim to write something to disk (triggering a scan): eg, sending an email, viewing an image, writing a log entry, etc.
Not a Windows Update, the fix is coming as part of the Windows Defender definitions updates rollout process.
That's basically where I'm at with it. I was familiar with Slackware's init, I was familiar with Debian's init. Can't remember off of the top of my head but I believe one used SysV, the other used BSD. Either way, not that complicated, easily fixed by hand if necessary.
If a replacement for the various fragmented inits was limited in its scope then I would be fine with such a replacement. Trouble is, this seems to have taken the kitchen-sink approach, throwing everything in whether it's needed or not, and worse, it seems to have broken the tenet that everything is editable with a text editor and some patience.
Yeah. There's very little in the "replace with config" space that couldn't already have been accomplished with other tools, or by writing their own. That's essentially what you already have with superservers like xinetd or even DJB's daemontools, which can successfully be hung off the edge of an otherwise opaque rest-of-the-init-system. Most importantly, that provides ISOLATION and a defined interface without demanding changes everywhere else.
If someone wanted a new fancy parallel superserver for socket systems, that's fine. If some of "/etc/rc" and "/etc/rc.sysinit" (in RH-land) was to be optimized or rejiggered or (heaven forbid) replaced with a busybox-like super binary that does a bunch of stuff, fine. But those two things are orthogonal and should have been treated as separate projects.
The ironic thing is that a big chunk of what systemd was originally sold as ("Faster boot speeds!") was achievable with what should have been a third project in RH-land: Following Debian in changing /bin/sh to dash instead of bash.
Oh well.
Yep. The problem isn't that the government isn't "digital" enough, the problem is that it's run by people who wouldn't recognize the scientific method if it was served to them on a plate with a sprig of parsley on top.
If he goes to Silicon Valley all he'll find is a bunch of people who want to sell him a lot of useless new computers+software under a lucrative government contract.
If he goes to Silicon Valley all he'll find is a bunch of people who fetishize 'data' and algorithmic analysis over critical thinking, reasoning, reliability engineering, or domain knowledge skills. We tried this in 2008 and a bunch of the data experts failed then too, because this shit is actually hard and usually doesn't get solved by the creative destruction of a new image recognition app to replace bureaucrats.
Face it, they both suck balls, you are just more familiar with a particular ball sucker.
No. People writing shell scripts that don't know how to suck balls.
Init scripts aren't complicated, but different Unices (even within the SysV tradition) have solved various problems different ways. Beyond lack of shell knowledge, most of the really horribly written init scripts I've seen as an RH admin have been from Debian-focused writers who aren't familiar with RH conventions. RH makes stuff super easy with /etc/init.d/functions to do most of what you need. And most stuff that isn't included is dealing with some weird issue with the daemon you're starting to begin with.
Admittedly, maybe that lack of cross-distro drop-and-replace was a reason to standardize on something, but that's kind of what LSB guidelines were there for. We didn't need systemd, let alone allllllll the other shit that systemd forced down our throats in its Giant Leap Forward.
Even more lamentably there are reports that systemd is causing intentional incompatibilities. This isn't just a repeat of information that isn't as good as second-hand, so don't take it seriously, but merely as something to watch for.
I suspected/expected that would occur. Any pointers to background there?
Well, maybe. The freeway berm hadn't been completely uncovered before the main part of the freeway needed to go in.
More to the point: Have you ever been to San Diego? We have huge canyons, valleys, and hills all over the place even just within the official city (proper) limits. I guarantee with more ground penetrating radar or other scanning techniques there are other samples waiting to be found.
Sure working outdoors will make you lose some salt through sweat, but unless you're crossing a desert on hard rations that's doing you more good than harm.
More than that. If you're working all day in the hot sun and only drinking water, you're at real danger of heat cramps, followed by heat exhaustion and something worse.
You don't need *much* salt, but if you're sweating all day you need SOME. Gatorade or another electrolyte solution is carried on ambulance rigs in hotter areas for just this purpose.
Once a phone call is initiated it poses little or no risk as it continues. If I start a phone call while I'm at a stop light and continue with it I'm really not posing any additional danger to anyone. By comparison taking your eyes off the road to read and write a text message is inherently dangerous any time you are attempting to drive while doing so.
Ironically, the initial justification for cell phone bans (before the era of smartphones) was the exact opposite. Cell phones with physical buttons were easy to dial with, could be done by touch many times, and scrolling a linear list of contacts was easy. The "concern" was that an emotional call (or any call at all) would be distracting in a way that listening to the radio wasn't. This is why other "fiddling with things" tech, even available then, wasn't included in the ban here in CA. (I'm talking about things like dedicated GPS receivers, and classic iPods.)
Text messaging alone didn't seem to really take off until the early-mid 2000s in the US outside of certain circles.
Nowadays, of course, it's almost completely the opposite. Phone calls are rarer, and your mobile device is multifunction and used for all sorts of things by the broad populace on a regular basis.
I have to generally agree with the grandparent/first post though. If EVERYONE is doing it regardless, the draconian law should be changed so something more meaningful and fairer to enforce. I'd say more people are breaking the cell phone law than are breaking speed limits -- and that's something. In CA you're not allowed to have your cell in hand even stopped at a traffic light which (as annoying as it is to have to honk at someone that the light's changed) not as much harm as that ticket would seem to imply.
My suggestion: "special circumstances" for injury accidents and reckless driving / moving violation crimes with hands off the wheel and a renewed emphasis on "Don't do distracted driving" vs "Don't look at your cell phone". Let's be realistic, and we'll have much more compliance.
Congratulations, folks... BK has successfully demonstrated a giant vulnerability in Google's (and Amazon's, and Apple's...) product - it responds to voices from people it doesn't know, and the default access phrase is well-known.
Maybe instead of whining about Burger King, you can pressure your vendor to fix their design flaws. Or better yet, disable all voice recognition/spying devices and banish them from your house completely.
Just a few examples, but beyond the google I'm especially aware of Amazon, Apple, Microsoft, and Exxon. Feel free to add your favorite corporate cancer here.
Exxon? Really? That's fairly retro. Ranting about Standard Oil and, to some extent, Baby Bells that aren't directly involved in cell tracking, seems rather quaint.
Replace Exxon with Facebook and you've got a far stronger argument. Exxon can charge me for oil and oil products. Facebook has enough privileges on any given smartphone to track me 24 hours a day and manipulate my interaction with most of my friends (while Google controls my interaction with rest of the world).
Far more important.
...
I guess stopping everything that black guy tried to do was the primary objective.
Justice Sotomayor and Justice Kagan might have some words about your dipshit contention.
^ Mod parent up. That's entirely the issue. It's like he's intentionally designing something *MORE* complex but slightly more efficient in the hopes that it'll be a justification to get the humans out of the loop entirely.
Interestingly enough, some of the posts I see on Facebook claim that the investment in robots and AI is happening because of the increase in the minimum wage...and something, something illegal aliens. I hate my Facebook feed.
The operative word is "because". It was already going to happen due to the laws of economics, but if it happens gradually enough there's a much higher chance of society successfully adapting and digesting the changes through longer-term programs.
Raise the minimum wage too quickly too high ($15 in Podunk, USA), vastly increase costs for employing people (30hr/week = health insurance), and you shock the system, forcing an earlier-than-expected look at capital investment.
Add in a Silicon Valley that's oblivious to any problems outside of the liberal, progressive, Bay Area bubble they live in, with priorities completely out of whack with the real world so long as the IPO money keeps flowing in, creating automation and tech simply because "they can now" and with an undying, almost religious belief in the merits of technocratic efficiency (like good little central planners), and you have a perfect storm of circumstances for mass layoffs and accelerating automation.
Without the ability to digest these changes, either the tech oligopoly gets nuked, mass revolution occurs (of which Trump might be the precursor), or we'll continue spiraling downward until the technological singularity hits... at which point all bets are off.