Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:Sure, why not? (Score 1) 178

Actually, in many countries, the pager infrastructure has been shut down. Where I live, the pager infrastructure was turned off around ten years ago. Nobody cared.

Are you sure you're not confusing that with analog cell service? That has indeed been shut down in most places, with very, very few exceptions globally (mostly in extremely rural areas where people haven't wanted to go to satellite service). Pager frequencies in a lot of places is still going very strong, for precisely the reasons indicated in the discussion.

That's even moreso the case depending on government needs in your jurisdiction. If there are Important Civilian Responsibilities, then the pager network likely still works, since they're probably not using milcom but may need to function when the cell towers are out.

Comment Re:Pagers shared in work group for emergency conta (Score 1) 178

You can have a single contact phone number that forwards to the persons on call cell phone based on the time of day, day of the week, or whenever you switch shifts.

And that's why you don't work in emergency services. Reliability Engineering is a thing, and every additional link in the chain adds additional failure points.

I like Google Voice, and Skype forwarding, and VOIP conference switches, and all that too... But a physical hand-off is much more reliable.

Comment Re:My what? (Score 3, Informative) 38

Way back in the primordial ooze of the early-mid 2000's, MySpace actually gained initial notoriety as a place for musicians and bands to congregate. That was one (small) reason why it always had good media functionality (for the time)... Auto-play MP3's, highly visual backgrounds, CSS, etc. (The other 85% of the reason was so that people could post sparkly glitter GIFs...)

When it got re-purchased after Facebook took over both the upper and "lower" classes of the internet social media space, MySpace decided to try to get back to its roots somewhat as a band-catering destination.

Who knows if it'll ever succeed (again) at that, but the battle for general social media presence is long-since over, so they had to do something with it.

Comment Re:"you don't have to be very accurate" (Score 1) 255

Actually, for the US, you don't even have to hit anything.

A single nuclear explosion on the ground that hits an area of moderate importance would have tremendous geopolitical implications (to say the least), combined with probably a trillion dollar shock to the economy.

Three nuclear explosions somewhere 100 mi above the central US and West and East coasts would cause an EMP-triggered cascading failure of most consumer electrical devices for good, and most parts of the power infrastructure for months... if not years, considering the backlog of repair that would have to be coordinated and attempted without the use of power itself. In the meantime, countries not affected will use the effective absence of American involvement to promote their own agendas.

"Vaguely close, or in the right direction" is perfectly fine for nuclear effects.

Comment It's their service; what's the problem? (Score 1) 106

Perhaps this was written by someone too young to remember 3G video services.

Strangely enough, Verizon also doesn't charge me for receiving texts from their own customer support center, or "Fortune of the Day" service, or those chintzy CNNgo mobile .3gpp clips back in 2006, or NFL video, or any of the other benefits of cobranded services that carriers have offered. I fail to see how this is any different.

In fact, this is argueably LESS of an issue than T-Mobile's deal with the video services, simple as a result of it not being co-branded. If "Netflix by T-Mobile" was an actual thing, there'd be absolutely no room to complain at all.

Comment Re:Gonna get lambasted for this but... (Score 1) 699

In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough?

Yes. There's a reason Big Red Buttons in datacenters usually have a protective cover on them.

And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?

I've absolutely never said that the motherboard issue isn't a problem. In fact, I'm not sure I've seen *anyone* say that *anywhere* online in this entire debate... What IS a problem is that a random github project has control over the types of things that used to be decided at a much more distributed level. Complaints to distros are now sent upstream, where the self-described cabal decides what does and doesn't fit into their agenda for the Linux userspace.

No one asked for this.

Comment Re:Gonna get lambasted for this but... (Score 1) 699

You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?

Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:

Jóhann B. Guðmundsson 2016-02-02 16:42:09 EST

This got closed as WONTFIX upstream no need to carry on with this here...

Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.

Comment Re:Gonna get lambasted for this but... (Score 1) 699

It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.

Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.

The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.

Comment Re:Gonna get lambasted for this but... (Score 1) 699

Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.

No, of course a tool like that would have a reason to exist, just like there are OS tools *now* that can flash firmware, reset BIOS variables, or whatnot. (Whether it's secure to have host-OS level access to those types of features is a different, albeit related question, of course...)

The problem is in what you've posted:

a tool other than init

/sbin/init doesn't need to do anything with BIOS or EFI variables; /sbin/init just needs to init. We've already booted.

If there are OS tools (like update_firmware from Dell's OMSA toolkit) requiring more access, then let them handle whatever they need to handle. And if they break, or do something stupid like leave something in read/write mode on the filesystem that can cause you to accidentally accidentally brick your server, then we get to blame them.

We don't want or need systemd to be involved in this, and we really don't want or need the systemd developers involved in this. No one died and made them benevolent dictators over the Linux userspace.

Comment Re:Gonna get lambasted for this but... (Score 4, Informative) 699

Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?

It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.

As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:

If the authors of systemd didn't want to have to be smack in the [middle] of issues caused by disk mounts, perhaps they shouldn't have assumed disk mounting duties from other projects... nor advocated the removal of the easily adjustable init script which controlled them.

Just a thought.

And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:

We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.

Slashdot Top Deals

"The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- Richard P. Feynman

Working...