Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Important to note (Score 1) 357

Yes, but pretty much *anything* can be psychologically addictive, so claiming it as a feature of a particular thing is a bit disingenuous. Not that some things don't have a wider or more intense appeal - I imagine far more people are addicted to chocolate or video games than horse droppings for example.

Comment Re:Duh (Score 1) 712

1) All the major stakeholders seem to have agreed that systemd is "good enough", that's exactly the problem, isn't it? The end users (minor stakeholders) aren't happy with the decision of the major stakeholders upstream.
2) absolutely, no argument.
3) the coupling is now between systemd and other software, where previously it was with "all the alternate implementations of the subsystems this software depends on could be implemented". I'm not seeing how the second is an advantage.
4) agreed. But we do have a pretty good idea of what a "desktop" and a "server" look like. The biggest down side I see is that a lot of those alternative modules that might be handy for random alternative hardware will lose much of their developer pools.

Comment Re:Mars isn't going anywhere. (Score 1) 173

At your destination you have plenty of rock/sand/dust to construct shielding, plus the instantaneous 50% reduction in cosmic radiation thanks to the planetary mass on landing. In transit that's not an option, it would raise the mass constraints far too much for current propulsion systems. And we're a long way away from effective magnetic shielding.

Orbital insertion requires that you be going slow enough to pull it off. Ceres low mass means you orbit it at very low speed, so you have to approach at very nearly its own orbital velocity. And you only have maybe a month to get from Earth to your destination before the travelers suffer permanent radiation damage, according to all the various Mars plans I've heard. You can do nice orbital insertions f transit time isn't an issue, with humans on board you're in too much of a hurry and have to slow down at the far end. Ceres is roughly 2.3x further than Mars at closest approach, so you need 2.3x the average speed to reach it in the same time window. Which translates to 2.3^2 = 5.3 times the kinetic energy (K=1/2mv^2). Its orbital velocity is also substantially slower than Mars, so you have to slow down further (18km/s versus 24)

If the centrifuge doesn't spin in the same plane as the surface then for the bottom half of your rotation real gravity will be pulling you "down", while for the top half it will be pulling you "up". Net effect "gravity" will the pulsing or strobing at your rotational frequency. Though at only 0.03g you might not notice the difference. What I described is pretty much the "spinning walls cylinder" or "spinning suspended chairs" carnival ride, rather than a ferris wheel spinning fast enough that your seat always points away from the axis.

I didn't say spin-stabilized concentrators would be good for Mars. Mars gets ~3x the sunlight to begin with. Freefall habitats get practically free spin-stabilized solar concentrators. Ceres gets neither.

The ocean doesn't wear sand into spheres, no. At least not as fast as new ragged sand is produced (though those tropical paradises with long stable beaches do tend to have much smoother sand than comparatively rocky ones) . But it does wear down the sharp edges it had initially. And I don't care about thrown around dust on Mars - the rovers have proven it's a non-issue. Clinging dust though is going to work its way into every seal and gasket you have, and the sharper it is the faster it will destroy them.

Comment Re: Cost of access is key. (Score 1) 330

If/when survival becomes an issue, it would be nice if we already had a thriving space empire, because otherwise there's probably no way we can hope to evacuate more than a tiny fraction of the population before everyone dies, especially if we don't even have the resources to keep industry alive on Earth - what exactly will we use to build the first steps into space? Invstment is best done when you have lots of excess wealth. As for wealth - well, that remains to be determined, but several serious groups seem to think rare minerals can be returned to Earth at a profit, even with the current state of launch technology.

As for other motives - frontiers seem to be good for morale. And frankly, the expense of taking the first steps toward industrializing space pale in comparison to what we're already throwing away on pointless wars that do nothing but enrich special interests and advance the power of the authoritarian state.

Comment Re:Duh (Score 1) 712

Except the kernel really isn't that - maybe you could argue that it abstracts the CPU and some basic I/O functionality - but sound subsystems, sophisticate plug-and-play support, power management, networking, etc,etc,etc... do you really want all that rolled into the kernel? There's a LOT of stuff that gets piled on top of the kernel before you get to the desktop environment, what's wrong with putting an abstraction layer between the GUI itself and all the gooey goodness it depends on. As a developer I tend to find such abstraction layers, well positioned, can dramatically simplify the conceptual space I'm working in and let me focus on actually improving things, rather than managing the hodge-podge of modules doing the work behind the scenes. .

Comment Re:Duh (Score 1) 712

A fair point, and I do agree that systemd is likely much better suited to desktops than servers. Perhaps it's finally time to begin to fork the two at a lower level, since that very variety seems to be the source of much of the difficulty Linux has offering a competitive desktop experience. Basically consider systemd to specifically be a low-level component of desktop environments and other "shrinkwrapped" distros.

As for the smaller attack surface - as I understand it systemd is actually very modular, and you can leave out most of it in your distro if you so choose. The real problem is (I think, I'm pushing beyond the point that I've paid much attention to) is in the customizability. It seems like systemd expects its modules to operate in a very specific way, which would seem to drastically reduce the options for substantially different implementations.

Comment Re:Duh (Score 3, Interesting) 712

I would say an important question is, did the morphing happen before or after widespread adoption? And as I recall it happened well before. In which case I would argue that the starting point is really fairly irrelevant, and the actual "crimes" are:

1) calling an OS abstraction layer an init system when it clearly is far more than that (that seems to be perpetrated primarily by the detractors)
2) allowing a single party to tightly control the abstraction layer (though it does seem that such large-scale projects do need some sort of a singular "choke point" in order to ensure widespread compatability)
3) the discarding of lots of low-level components with large fan communities.
4) Having an OSAL at all? Though frankly, I think it's long overdue - one of my greatest annoyances with Linux is that practically every piece of nontrivial software seems to need to include explicit support and custom binaries for every major distro branch it runs on. That's a huge drain on developer time and energy, and one of the main reasons I've never done much Linux programming. Contrast to Windows where, with some fairly modest self restraint you can create a single binary that will run on everything from Windows95 to Windows10, and even Linux via WINE.

Frankly (2) is the only one I see as a real problem, and I'm uncertain how big of a problem it actually is. After all systemd is still fairly modular, just incompatible with most of the pre-existing modules already out there. And the individual modules are mostly under the control of other groups. And it's still GPL, so if the systemd group proves excessively abusive of their power there's nothing stopping the downstream distros from forking the project, provided they're willing to re-adopt all the maintenance headaches they adopted systemd to escape.

Comment Re:Duh (Score 3, Interesting) 712

And they don't - one of the main complaints people have, unless I'm mistaken, is that systemd isn't just an init system, it also wraps up a whole lot of things into a "low level system manager". You can certainly complain against that on grounds of ideological purity - but that's a completely different conversation.

So we have something-that's-far-more-than-a-window-manager depending on something-that's--far-more-than-an-init-system. There's certainly arguments to be had about design decisions, but they can't be had if you insist on using irrelevant terminology.

Comment Re:Cost of access is key. (Score 1) 330

No guilt about it - there is no shame in admitting your ancestors weren't always the most competent people in the world in all fields - that's true of pretty much everyone, and denying it is only an exercise in self-deception.

As for "brute force" being silly... you may be right. I was trying to capture the idea that any idiot with the right equipment and some basic training could get the job done. Polynesian navigation by contrast was one of those things that took personal mastery. Perhaps a reference to graphical development environments or script-kiddies would have been more on-point.

Comment Re:If we're going systemd, we should go full throt (Score 1) 712

I agree with binary log files having some serious issues, and I can easily imagine that replacing the logging system with it's predecessor is an ugly hack.

I wonder though how difficult it would be to replace journald with an interface-compatible logger that actually outputs good old fashioned text logs instead? Knowing nothing about journald or it's interfaces, it seems like it shouldn't be a huge problem - just fork off journald_txt, changing only the actual file output components. I would assume all the relevant data still enters the logging system, I mean there *is* a dedicated journald log reader, right?

Comment Re:Yes! (Score 1, Insightful) 712

As someone running OSX on one of my computers, I can think of some problems:

1) Constant OS upgrade costs
if you don't stay on the treadmill you rapidly start losing support for native software

2) Lousy cross-platform support
If you run a lot of cross-platform software, the OSX versions tend to suck - they may be functionally complete, but OSX usually only gets a basic port of the 'nix version designed to run on an X-windows shim, and there's lots of minor bugs and interface inconsistencies you have to deal with.

Yes parallels can be great, but if I'm running most of my software in Windows, what exactly is the point of having OSX and it's expensive hardware* in the first place? All I've done is add a second OS I have to take care of.

* yes, these days the hardware (mostly) no longer has a huge markup for what it is, but what it is is grossly overpowered for what most people actually need.

Comment Re:Duh (Score 5, Insightful) 712

As I understand it, as someone who could care less one way or the other, systemd isn't a solution for end-users, which is why you don't see any substantial changes. Its a solution for *developers*, freeing them from having to deal with the mountain of hacks, kludges, and assorted ugliness necessary to provide modern desktop-environment features through the decades of cruft and "ideologically pure" compartmentalization provided by the lower levels of Linux.

It doesn't offer new functionality - it just removes a maintenance nightmare for Desktop Environment developers, allowing them to focus on actually working on a good DE, rather than all the ugly backend stuff behind the scenes. The big issue, aside from ideological purity, is that in systemd massively redesigning that backend stuff there was inevitably a lot of lost functionality - you can't replicate the functionality of decades of accumulated cruft overnight. And major DEs don't want to wait until there's complete functional parity to adopt it, for a couple big reasons (and probably many more I haven't thought of):

1) Waste: if they plan to adopt the project eventually, then the longer they wait, the more wasted work they do maintaining deprecated systems.

2) Momentum: you want to adopt a project when it's both "good enough" and has a thriving developer community in order to help maintain its momentum. A project no one uses is eventually going to start shedding developers, and may never reach functional parity at all (see GNU Hurd, etc.)

"Necessity is the mother of invention" is a silly proverb. "Necessity is the mother of futile dodges" is much nearer the truth. -- Alfred North Whitehead