Comment Re:News Media (Score 1) 110
It couuld be useful for one thing: If a list is obtained of who supported or applied for this bullshit, I'd consider that an overall win.
It couuld be useful for one thing: If a list is obtained of who supported or applied for this bullshit, I'd consider that an overall win.
I'm not sure I understand either. How are you using a foreign (i.e., non-American or non-Canadian) phone number on T-Mobile?
Texting or receiving SMSes from my friends in Europe?
T-Mobile blocks that, even on their "all included" plans, and even though it doesn't cost them a dime.
You misunderstand - read again.
That you can use your own mobile phone in foreign countries, also for texting, isn't the issue. I never said it was.
However, you cannot text or receive texts from someone who has a non-American/Canadian phone number (even if on T-Mobile) without paying $10 per month extra for T-Mobile turning off the blocking.
The T-Mobile data plan is nice, except for not getting high speeds most places outside big cities and their suburbia.
But they nickel and dime you for everything else. Even with their top plan where everything was supposedly included, a friend sent me text messages from his T-Mobile service, and I never got them. It turned out that for the privilege of sending or receiving SMS to or from other countries, you have to pay T-Mobile $10 extra per month, despite it not costing them anything extra, and even when the people in the other end are also on T-Mobile. Pure money grabbing.
From TFA:
It also remains a bit frustrating to me that the carriers are allowed to bill you for data amounts without actually having to show you the URL endpoints related to each data packet.
Um, wot? First of all the endpoints are not URLs - presumably he doesn't know the difference between socket addresses and URLs.
But to present a list of each data packet? I don't think this guy has any idea at all of how networking works. Even if his phone operated with an X.25 1500 byte packet size and everything he sent or received were even multiples of that, a 3 GB usage would then mean at least two million lines listing endpoints. In real life usage, much more.
I'm not sure. A typist generally won't hold down a button for several months as this person allegedly did.
A brainfuck programmer who needs to access a big chunk of memory, on the other hand...
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.
Elegance and truth are inversely related. -- Becker's Razor