Comment Re:it started with smartphones (Score 1) 130
No, phones already had the capability. A telephone without a microphone would not go over well.
No, phones already had the capability. A telephone without a microphone would not go over well.
Slashdot: Olds for nerds, stuff.
Note the words "up to". That does not mean "typical" or "guaranteed".
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.
And I disagree with the AC you replied to that Torvalds has god complexes. Not so - he's quite capable of changing his mind as situations change, which his change to discard odd/even is just one example of. He has made mistakes in the past, and will probably be the first to tell you. However, he's a leader type in that he's willing to make hard decisions even when they could potentially be mistakes.
Indeed.
2.0 -> 2.2 -> 2.4 -> 2.6 all heralded major changes, while 2.6 -> 3.x did not.
I think there should have been one major lift (to 2.8?) in there with devicetree - that's a big change that introduces lots of potential incompatibilities and required changes to userland. But that one went in a minor number, which seems rather wtf to me.
My recommendation: Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.
Also make a marker for whether a stable kernel is also designated long term stable, because right now you have to just know which ones are LTS, or you have to look it up at Cox' or Morton's sites.
Did you even try it?
Outside production, yes.
In production, no way. The amount of work required just to try was determined to be immense, and there were incompatibilities from the start that seem prohibitive - like systemd taking over cgroups, while we already use cgroups for our own purposes, and hal not working because of incompatibilities with the "improved" dbus, and we rely on user-triggered external hardware detection, not system-triggered.
I currently run a test system with EL7 that does not need cgroups and hal, and when it works, it is not much of a problem - but that can be said of any software, regardless of quality. It's when it doesn't work, and a boot crashes that systemd leaves you stranded. If you haven't provoked boot problems to see what happens, and how to recover, you have not truly tried EL7.
Along the way, your RHEL6 will be fine, and it will grow cold, like they all do, as will your skills. I don't particularly care for systemd, but I learned it in a couple of hours, and yeah, it works.
The problems with systemd is when it doesn't work. You risk a system that's inoperable - you can't boot to single user mode and you can't even check logs from a different system, because they're not humanly readable and not committed. And you can't single-step through the tasks one by one and see what happens.
Never mind that it's also MSDOS
And at the first error - boom, you have a system that can't be brought up or troubleshot. Better keep a bare metal backup handy.
What this sysadmin cares about isn't how fast a system boots[*], but that it's stable, consistent, has as few dependencies as possible, is debuggable when the shit hits the fan, and that no one failing part can bring down the whole house.
[*]: When an IBM system spends ten minutes in pre-boot running self-checks and enumerating all the SCSI disks, I couldn't care less whether it cuts the boot that follows down from a minute to half a minute.
Dbus, HAL, systemd, all this half-implemented GUI stuff... it's too unpolished and counter-intuitive for the clueless, and too complex for the clueful, basically because they keep trying to reach for the former market at the expense of the latter.
I could live with hal. It provided useful functionality. Although whoever created the command line interface to hal must have been a masochist who loved typing and had an aversion to allowing more than one qualifier per command.
for udi in $(hal-find-by-capability --capability storage); do
if [ "$(hal-get-property --udi=$udi --key storage.removable.media_available)" = "true" ]; then
hal-get-property --udi=$udi --key block.device
fi
done
Yes
try (this.that->matter(opinion).is())
Imagine a language with no fluff, no cruft, no boilerplate. Everything is essential and concise. You have something akin to either assembly or too-clever Perl. The fluff is necessary. The fluff provides context, readability, and maintainability.
It also provides its own bug opportunities. Indeed, from looking at what Coverity finds, most defects wouldn't have existed without the fluff.
I'm not advocating that people migrate to assembly or perl, but whenever you cannot point at just where something happens, you have overused abstractions.
The Cox "Browser Alerts" seem to only come from three IPs. I blocked them at my router and haven't experienced any problems. I don't have those IPs handy, but found them when NoScript listed them as choices to Allow/Forbid. (In my case, they were "letting me know" that I should upgrade from a 2.x to 3.x DOCSIS modem.)
They still modify the content. Say I use wget to recursively fetch a web site I run on the outside somewhere, and burn it to a CD for someone to look at. Then they will see the content that Cox inserted. That's not cool at all.
Something is wrong if you have to rely on SSL to protect you from your own internet provider!
Don't buy a tv, spend more time on tracker sites and slashdot instead.
That won't necessarily solve the problem. The only high speed internet provider where I live has rewritten HTML on the fly to serve their own content. I would not hold my breath that they won't do the same for video.
Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.
People are loath to publish new projects because keeping them running with systemd and all its dependencies in all possible permutations is a full time job. The whole "do one thing only and do it well" concept has been flushed down the drain.
I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7, but install new systems with RHEL 6 (or CentOS or ScientificLinux 6) and use 3rd party repos to get new stuff.
And that Red Hat sales go down is not just due to the turn in economy. It's people looking elsewhere, for something that lets people do their jobs. Systems that let you write simple scripts where you don't have to look up layers upon layers of abstractions to find out things. Where things are in plain text in known locations and names. Where you can copy configuration files from one machine to another without having to rewrite them or assemble a package of ten files from five different places.
Where the assumption isn't that when you install something, you want to run it (setting up HA on systems with systemd is a big pain, and failing over is an even bigger pain).
Binary logs without even forced flushing? Config changes that require reboots? No sane concept of runlevels? And I can go on and on.
Systemd is made for the convenience of single programmers on single laptops. It's anathema to system administration where you need to keep control.
Or use a USB key formatted to NTFS.
Or notepad2 if you don't want bloatware.
Or just install cygwin and use red like Ken intended.
There's nothing worse for your business than extra Santa Clauses smoking in the men's room. -- W. Bossert