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


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Will SystemD feature creep ever stop ? (Score 1) 553

by Sipper (#48849493) Attached to: SystemD Gains New Networking Features

I'm bummed that Ian's GR concerning init system equality failed

Why? What that GR said was that packages that didn't support all init systems would be removed from Debian -- i.e. if it had passed Xfce4 would simply be removed.

This is the GR:

the intent of which was to insure that alternate init systems continued to work, not to remove packages that didn't support that. Making a bug RC could potentially cause a package to be removed if the bug was ignored and unfixed, but any DD can NMU the package to fix an RC bug at any time, so packages like Xfce4 being removed as a result of an init system RC bug is fairly unrealistic IMHO.

Comment: Re:Will SystemD feature creep ever stop ? (Score 1) 553

by Sipper (#48818637) Attached to: SystemD Gains New Networking Features

Have you tried to run Debian 8 without systemd? Systemd-less laptop is not just usable anymore at least on XFCE; usb automount and anything related to gvfs is gone, laptop special keys (backlight, volume) do not work, etc.

Yep, I tried my best to install Xfce4 without systemd... that didn't go well, even on a desktop system. KDE can run without running systemd as the init system as well but exhibits several annoying quirks -- it cannot tell when the system is internet-connected, so for instance KMail2 will instantly try to get mail on login and then complain for every account that the connection fails.

I'm bummed that Ian's GR concerning init system equality failed, which means that going forward systemd is the only init system that has to work in Debian, because devs have the option not to care if changes to the packages they maintain break other inits. (Hopefully that won't happen, but based on what I've seen devs say in [debian-devel] I'm not terribly hopeful.) I'm also bummed that Debian had to drop the kFreeBSD port as an official port for Jessie. Ugh.

So yeah needless to say this transition is ... rough.

Comment: Re:What has happened to Linux? (Score 1) 553

by Sipper (#48818587) Attached to: SystemD Gains New Networking Features

What the hell is happening to the Linux ecosystem?

I've been a Debian user since late 1999 and I very much sympathize with what you've said here. Over time I've gotten increasingly deeper into Debian, and I also find I have some nagging issues with systemd that I didn't have under sysvinit/sysv-rc. Thankfully I've never been a heavy Gnome user, but I've been testing Gnome 3, Cinnamon, and MATE lately, and find that I heavily dislike the current Gnome 3 in Debian Jessie, can deal with Cinnamon, and like MATE the most of the three. Agree re: Firefox/Iceweasel, though I can still tolerate it's current version in Sid.

The biggest problem I have with systemd isn't on the technical side but rather the social side; the issue has been very devisive -- no other issue to date has set groups against one another in such a heated way in some time now. A number of Debian developers have quit or dropped out of teams over it, let alone the heated threads in [debian-devel] about it.

Right now my short-term plan is to ride out the Jessie release by sticking with sysvinit on servers but use systemd on desktops to gain more familiarity with it. I don't have any plans to switch to FreeBSD, and I'm upset that Debian dropped the kFreeBSD port from being official for Jessie. :-/ It would have been nice to have that as a fallback.

Re: Debian Testing -- the stability of Testing has been the issue of ongoing discussions at DebConfs so unfortunately this is a known issue. I can't say I know all of the reasons behind this problem, but I think one of them might be the automatic removal of source packages within 30 days that have RC bugs, and another being that transitions from Sid -> Testing can be such that source package versions in Testing can be out-of-sync compared to Sid. So the irony is that Sid / "Unstable" is actually more stable than Testing, almost all of the time. Sid doesn't get support from the security team though, so I don't consider it good for servers. So because of this I avoid Testing altogether, and run Stable for servers (and "customer" desktops) and Sid for my own desktops. That seems to work except of course that I run into some frustrations with packages for Stable being a bit old.

Anyway -- good post. Best of luck in whatever you choose to use for your free OS.

Comment: Re:Fuck Me (Score 1) 553

by Sipper (#48818207) Attached to: SystemD Gains New Networking Features

systemd is "optional" in Debian Jessie in that it's possible to uninstall, but systemd gets installed by deafult in Jessie, and it's also not easy to remove depending on what you're looking to run on the machine. Gnome depends on systemd heavily, so I'm not even sure if it's possible to remove systemd without removing Gnome. I've tried to run a Jessie system without systemd installed and it's ... difficult. You can have systemd installed without using it as the PID 1 init, but that too leads to unexpected behavior. Both Gnome and KDE have been built today with the assumption of systemd being PID 1, Gnome depends on logind to be able to log in, and so on.

The other init systems still work for now in Jessie but the GR [General Resolution] that Ian Jackson from the Debian Technical Committee started to declare that keeping the other init systems working was RC [Release Critical] was voted down, which means that systemd is now by default considered the only init system that has to continue to work. Because of this GR's defeat and the backlash on Ian for bringing it up, he's since resigned from the Debian-TC which I think is a great loss. :-( (My big thanks goes to Ian Jackson for his work within the Debian Technical Commttee.)

I haven't yet tried OpenRC outside of VM but IIRC in the VM it worked fine for me. Unfortunately the OpenRC packages (and documentation) in Debian were not in good shape at the time fo the Debian-TC discussion and decision on the default init system for the Jessie release.

Comment: Re:Ian Jackson (Score 1) 522

by Sipper (#48174907) Attached to: Debian Talks About Systemd Once Again

Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.

Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.

And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.

The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but ... Ian did bring this up in March...

Comment: Re:Amiga Floppies (Score 2) 171

by Sipper (#46833367) Attached to: Previously Unknown Warhol Works Recovered From '80s Amiga Disks

You apparently never had to put your C64 power supply in the refrigerator.

The C64 power supply used a 5v linear regulator rated for 0.2A - 0.3A less current than the C64 itself drew through it, so the part would have premature failure because it was underrated. Apparently/supposedly the difference was expected to be dumped as heat, and the supply was potted which made it very difficult to get to the part that failed and replace it... but doing so was necessary because the replacement supplies had the same design flaw. I did that replacement and after doing so the power supply looked terrible (I left it ripped open), but with a linear regulator that had a sufficient current rating it never failed again (whereas the replacement supplies all did).

Putting the power supply in a refrigerator sounds terrible (but dedicated), but then, so was the "correct" fix. ;-)

Comment: Re:Amiga Floppies (Score 2) 171

by Sipper (#46833305) Attached to: Previously Unknown Warhol Works Recovered From '80s Amiga Disks

I've heard of drilling through the potting material to remove and replace a fuse buried in there, but never that. What was the hope behind the refrigeration of the "brick"?

Yes, the C64 power supply was potted -- and after digging through it what had to be replaced wasn't a fuse, it was a 5v linear regulator. The problem with the C64 power supply was that the Linear regulator was designed for 1A, but Commodore was using it to pass 1.2A. This shortened the life of the part, and when it failed it required a huge effort to dig through it to find the part that was bad and replace it.

But I did exactly that. And unfortunately one generally had to do that if they wanted to end up with a reliable supply, because the replacement supplies had the same design flaw and would thus fail in the same way. Once I replaced the 5v regulator with one that was rated for 1.5A, it never failed again. :-)

Comment: Re:Slashdot is ridiculous (Score 1) 575

by Sipper (#46771447) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

I am the wrong person to get into the nitty gritty of it, but I believe this is handled by Side-by-Side dependencies (SxS) in windows. I have only very rarely seen dependency problems on Windows, even going back to the days when XP was new and 2000 still roamed the earth. Linux dependency problems are less common but theyre definitely a bigger issue than Windows ones.

Well, I was speaking of modularity in design terms, not about dependencies per se. Vista and above are known to be "more integrated" than previous Windows versions, and simultaneously nowhere near as modular for the base OS as most Linux distributions. [And as such I agree that dependencies are a bigger issue on Linux than Windows. ;-)] What I'm getting at is that on Linux a bug such as the OpenSSL problem can be quickly narrowed down to a particular package, whereby the code that needs looking at for a fix is much smaller that way. On a more integrated system the source of the error is likely harder to find, and once found more complicated to fix, than a modular system.

However this is speculation on my part, as I'm not familiar with nor involved in the design of Windows OSes, nor have I looked at any of the Windows source code, and I also don't otherwise have a way of making a "Linux vs Windows" side-by-side comparison.

Comment: Re:Slashdot is ridiculous (Score 1) 575

by Sipper (#46756579) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

The SSL flaw has been fixed and rolled out very quickly, it was not the first and will not be the last. How many known Security flaws for windows, IE and many other Microsoft products are out there, unfixed?

Could you explain why "Microsoft has a bigger problem with having to support old platforms" than anyone else? They seem to have vast resources and should actually be able to react quicker than others.


This is probably obvious, but the larger they get and the more "integrated" their system is (i.e. I'm thinking of the new level of system integration with Vista versions and above), the slower they're likely to be able to create correct fixes. I don't know this for a fact, but it seems as though the Windows system itself isn't terribly modular compared to other systems (Debian Gnu/Linux for instance) that have packages and dependencies. On a modular system focus can be placed on the "one package" that has a problem (if you can debug the issue down to the package level), but on a very integrated non-modular system where the source code itself is a guarded secret, that sounds like a difficult problem to deal with.

Comment: Re:Wanna give up on these guys yet ? (Score 1) 575

by Sipper (#46756375) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

At least it fails gracefully with a clean error code. In Linux world it would show up as a dialog with corrupted text and a mysterious "Invalid argument" error message written in some log. ;)

I wouldn't call "erorr 800F0092" to be a "clean" error code -- more like a bizarre confusing unintelligible error code. The errors in Linux can sometimes be frustrating too, or might even be hidden in a log like you pointed out, but they're never designed to be as unintelligible as many of the Windows system error messages are. On Windows there seem to be two kinds of error messages: ones for developers and ones for users; "error 800F0092" vs "check the cable", and there doesn't seem to be a whole lot in-between. At least on Linux systems you get a full range of them. ;-)

Comment: Re:Bullet, meet foot (Score 2) 575

by Sipper (#46756323) Attached to: Microsoft Confirms It Is Dropping Windows 8.1 Support

Or linux.

I wish that were so... unfortunately Windows still has the Desktop userbase majority by a wide margin, and that doesn't seem to be changing despite Microsoft's many steps towards making computer owners' lives more difficult. "Windows Genuine Advantage" that limits your ability to change hardware in a computer running Windows, licensing confusion concerning running Windows in a Virtual Machine, version confusion ("home", "professional", "enterprise", "ultimate", etc), UI confusion with Metro and the Office "banner"... and so on.

I wish Linux were "the answer" to this, but I've been running it on the Desktop since 1998 and I know it's not. A user trying to switch first has to go through a painful process of figuring out what programs they can use to do their daily tasks -- because they're not going to be running Internet Explorer or Outlook anymore, and the new programs have a different menu layout and (for the most part) different shortcut keys. If you've been working with a Linux desktop you've probably forgotten just how painful this transition was -- and it's not trivial. For people that are "stuck in their ways" and get anxious when they feel lost, this in itself is sometimes an insurmountable challenge.

Also the Linux ecosystem is very different, mostly relying on volunteer efforts with a few paid developers on the side. Being that this ecosystem represents less than 5% of the market, it's not an ecosystem that would be able to cope with the other 95%+ of the market suddenly needing support. And because it's mostly volunteers that help, users first need to figure out where to report issues (which isn't always easy), then there are issues concerning user demads vs helper pushback, sometimes leading to rudeness and communication breakdown, occasional elitism or ignoring problems, etc. It's "a different world" than Windows users are used to in that respect too.

And when you say "Or Linux", if the users given that advice knew to they'd ask "which one?" (i.e. which distribution?) Yeah... that problem too. Which window manager / desktop environment? That too. Etc.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

by Sipper (#46700535) Attached to: Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros

It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.

MITM can be an issue. More detailed information about the state of things at the link below.


Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

by Sipper (#46693199) Attached to: Not Just Apple: GnuTLS Bug Means Security Flaw For Major Linux Distros

I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.

You've skipped over the PFS key exchange portion used in TLS.


Maybe the MITM exploit you're talking about is possible, I don't know.

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

MITM attack.

That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.

Oh well. OpenSSL apparently has a vulnerability too. sigh :-/

Comment: Re:If GNUTls is unneeded, then create a NO-OP libr (Score 1) 144

And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.

I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing.

No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.

Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.

No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

Genius is ten percent inspiration and fifty percent capital gains.