Forgot your password?

Comment: Re:Simpsons Movie? (Score 1) 388

by drinkypoo (#48194115) Attached to: Manga Images Depicting Children Lead to Conviction in UK

I have to wonder how the judge draws the line between something like this conviction and, say, the Simpsons Movie, where Bart is rocking some full frontal on the big screen.

There's a difference, for sure -- one is funny and clearly a cartoon, whereas one sounds like it's purposefully sexualizing children.

right, but when people propose to ban virtual child porn because they argue that it promotes child abuse, they have to propose banning depictions like the one you mention, because that depiction could be used by someone for sexual gratification, and/or it could arouse those desires in them. Sure, it's a crude representation, but there are cruder ones on cave walls that we seem to be able to recognize.

Comment: Re:Moral Imperialism (Score 1) 387

by drinkypoo (#48194049) Attached to: Manga Images Depicting Children Lead to Conviction in UK

They want something different than the common-carriers rules, because it is "not like the phone system which used only one application."

Right, but that's actually a lie. It is exactly like the phone system which used only one application. In the case of the phone system that application was transmission of sound, and in the case of the internet system that application is transmission of packets. If you argue that these packets' different nature makes them fundamentally different applications, then you must also argue that carrying data on a modem call over the phone system is a fundamentally different application, and then you cannot state that the phone system used only one application. In fact, it had two, and yet they were treated exactly identically. That is, in fact, a strong argument in favor of net neutrality.

Comment: Re: Moral Imperialism (Score 1) 387

by drinkypoo (#48194031) Attached to: Manga Images Depicting Children Lead to Conviction in UK

The constitution is crystal clear about many things that the judges, in explicit violation of their oaths, have made mean something else entirely. Previous poster is quite correct. The experiment failed.

The experiment by a bunch of white male land owners, most of them slave owners, succeeded brilliantly. Its goal was to determine whether it was possible to use jingoism (nee patriotism) and bullshit to fool the subjects of rule into believing that they hold the reins of power. Guess who still runs the country? A bunch of white male land owners, who are now actually in charge of something superior to slavery for their purposes: corporatism. They buy the laws, and we follow the laws. They've criminalized homelessness, and used the government to buy over 25% of the nation's land for the purposes of their exploitation in the form of the Bureau of Land Management. Rather than homesteading it and handing it to private citizens, homesteading was suspended so that this land could be raped wholesale. It's allegedly held in our interest, but those who've tried to (for example) use some of it to build a thermal-solar plant found that it was only available for mining coal, drilling oil, running cattle on land which was deliberately deforested for that purpose and therefore preventing it from becoming reforested, and the like.

Comment: Re:UNIX Philosophy (Score 1) 401

by drinkypoo (#48194003) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

Unix wasn't even born with the now basic concept of "piping", it was a development over time.

It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.

The systemd developers really did their homework well when designing the systemd log implementation

No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless. Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read. If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.

I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.

Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?

Comment: Re:What? (Score 1) 401

by drinkypoo (#48193959) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

Imagine the 'fun' if you need to boot to a rescue disk, chroot into the server filesystem and bring up services while you fix a problem.

Who has to imagine? You can experience this right now with MacOS, which also has a unified system-starting daemon. And if it shits itself, you have to take all the steps manually. In early OSX you had a handful of commands to issue to get the system to boot past single-user mode, now there's just one, and god help you.

Comment: Re:What? (Score 1) 401

by drinkypoo (#48193945) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

On a desktop, systemd and firewalld make sense, [...] For a server, one wants reliability and security above all.

Sigh. On my desktop, I want reliability and security above all. People who don't want that are part of the problem. I chose a server-class OS as a desktop OS specifically because that's what I wanted! Now a bunch of wankers who can't figure out shell scripting want to replace that simplicity and durability with something fragile and complicated, and then they want to claim that I am the one with the problem when I complain.

The one thing that has kept the epic fails out of UNIX is the fact that the OS is made out of a lot of little subsystems. Replace bash with busybox, not that many programs would notice. Replace /bin/yes with busybox's yes... who cares. However, systemd breaks this philosophy. If something breaks, I can't just rename the binary, link in the busybox equivalent, and call it done. I'm dead in the water until a patch comes out,

And is that really what you want for your desktop PC? Me, I want it to work, and I want that work to be secure. That's why I maintain a Linux system even though I spend a lot of time in Windows. I sure don't do my banking there, and I don't even trust it to boot when I need it. I've got too much experience with the opposite happening. I don't want Linux turned into Windows, or MacOS. We have Windows and MacOS for that. If my boot time has to be a couple of seconds slower (and that is what we're talking about here, folks) then so be it. It's a fair tradeoff for useful logging of the boot process.

Comment: Re:That's all we need ... (Score 1) 401

by drinkypoo (#48193919) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

Yes, for the kind of people who run Redhat, which is a turnkey "lick and stick", "Call support", "it's someone else's problem" kind of Linux. Great. I would expect redhat users to fully embrace systemd. That's not a shock.

For the kind of people who run Debian, it's a big deal. At least, half of us. Half of us are apparently there only for ease of use. They should fuck off to Ubuntu and leave the rest of us alone, since there's already a Debian-fork for them.

It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well,

Sure, Solaris has, but AIX hasn't. So what? That was a post-acquisition move, right? And Oracle has a serious NIH mentality. It's not done until it requires Oracle RDBMS. Just wait.

Comment: Re:That's all we need ... (Score 1) 401

by drinkypoo (#48193907) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

The solution to yet another init system is to support even more init systems?

Congratulations on one of your typically ignorant comments. The current situation is to support many init systems, but Debian intends to destroy the current state. This project simply maintains the current state of affairs, rather than throwing up one's hands, saying "fuck it", and just adopting systemd.

Comment: Re:This one is different (Score 1) 401

by drinkypoo (#48193877) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

The fact you feel the need to engage in character assassination rather then technical discussion speaks volumes about you yourself.

The fact that you cannot distinguish between "then" and "than" and then have the gall to use the words "technical discussion" speaks volumes blah blah blah.

The character of a developer is not irrelevant, and your attempts to paint it as such are likely motivated by your own social failings, which you would like the rest of us to ignore.

Comment: Re:This could be really good for Debian (Score 1) 402

by drinkypoo (#48193867) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

Tell that to my girlfriend. She can do most maintenance on her workstation, but she had to have me look at boot deadlocks about twice a month, all because /etc/init.d/rpcbind and /etc/init.d/networking were in a race, and the NFS mounts lost.

Linux NFS needs help. We all know it. The solution is not to hide the problems with another daemon.

SysV rc is not 'perfectly functional' by a long shot. Both at home and at work I keep running into limitations that systemd solves.

Let's hear about them. Still haven't heard about any, just seen hand-waving.

Systemd comes with other bugs, and I've been hit with one or two of them, but they were, for me, easier to solve than SysV rc race conditions and deadlocks.

you mean failures of the linux NFS daemons.

If you're depending on NFS to boot, then you're a sucker. Because NFS hasn't got the love it needs, especially on Linux.

Comment: I dislike ESR more every day (Score 1) 195

by drinkypoo (#48193857) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

Anyone remember when ESR was known mostly for providing us with esoteric knowledge? Now he's known for spouting, and making bad decisions. This is one of them. Git is shit for the casual user. It might be the greatest thing since sliced bread for the hardcore developer who does massive merges, but for everyone else it makes life worse and not better. You can't resume a fetch, and you can't fetch a subdirectory. That means for example that I literally cannot work on Android-x86, because my rinky-dink internet connection cannot handle fetching the git repo. Or if it can, I never found the magical collection of switches that would do it. And I shouldn't have to hunt. There should be one command which fetches the current version, and none of the history, and there should be another command which fetches the history, and then there should be a command which does both. And all of them should have clear and obvious names, and there should be examples for each in the EXAMPLES section of the man page. Anything less is defective versioning software.

Git is shit, and anyone who says different is selling something. In this case, Linus is selling himself the lie that he didn't fuck up when creating git's UI, and ESR is reselling it... also to himself. If your tool needs massive documentation, then your UI is shitcakes.

The fact that git is shit wouldn't be such a problem if projects would still publish tarballs, but most of them aren't doing that any more, because they're relying on git to provide that functionality.

When you don't know what to do, walk fast and look worried.