Forgot your password?
typodupeerror

Comment: Wrong criterion (Score 4, Insightful) 94

No, the government's job is infrastructure, and other things that can be described as natural monopolies. If the start-up costs for a business are in the tens- to hundreds-of-billions, there isn't going to be much in the way of competition no matter what the industry is. If it's actually vital that said industry exists, it makes sense to nationalize it.

However, if competition is possible, it should be encouraged. There's no reason to nationalize SecureWidgetCo if a dozen people could take their place tomorrow, even if they only sell to the government.

It's clear that if the US Government wants to be sure of its chip supply, it needs to be in business for itself. The ultimate reason is not however that it's inherently inefficient for the government to enter into contracts with private companies, but that large scale microchip fabrication is so expensive that no (private, US) company is willing to do it.

P.S. With respect, if your response to this is that natural monopolies do not exist, please save yourself the trouble of responding.

Comment: Re:UNIX Philosophy (Score 1) 549

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

It's a matter of perspective. Being able to accurately track processes (via cgroups) is systemd's raison d'etre, and a natural part of this is to be able to start and stop services. In order to do that well, you're going to need to have some sort of idea about service dependencies and system resources. As long as you're going to do all the hard parts of init anyway, you may as well be an init system. Even so, it's not entirely necessary that systemd run as PID1, but it seems to have been coded that way. However, it's not the only service manager that does this: runit, daemontools, and the service managers for OSX and Solaris also handle init.

The other thing that is enabled by accurate process management is tracking user sessions. It's not strictly part of the mission statement, but it's not too much of a stretch, and no other project (besides the moribund ConsoleKit) is providing it. That would be why the major Desktop Environments are dependent on systemd, not because they want to, but because there's no alternative. So, it's not going to be enough to mandate that Debian be init-neutral, someone needs to sit down and either fix ConsoleKit (which was abandoned for a reason), or write something equivalent. I believe Canonical has made some steps forward there.

If you're going to argue against systemd, you should consider learning something about it. There is far more heat than light on the side of the detractors, and it does not help their cause.

Comment: Counterpoint (Score 4, Insightful) 243

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

Git's subtree / subproject management is extremely painful. The information manager from hell, indeed. I dislike SVN/CVS extremely, but they make much easier to do sub-repositories. For example, Arch's ABS is entirely under SVN, which works well enough for them, but using git the same way sounds like torture.

Comment: Re:UNIX Philosophy (Score 1) 549

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

However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL, the X Window system, the GIMP, OpenOffice? Is an init system more like one of these or more like sed and awk? That's not a rhetorical question. I'm a web programmer who loves Linux, but the kernal and start-up are still black magic to me.

Apache is monolithic in the same way that systemd is. It does not do "one thing". Nginx exists because Apache does way too much. X.org is also absurdly complicated, but at least they stripped out the print server. Wayland is the attempt to make it more pared-down. An init system is either complicated or bad at what it does, or both. I would perhaps debate about including Postgres as a piece of monolithic software, perhaps in comparison to simple data stores, but it doesn't stray too far outside of the definition of "relational database".

Maybe an init system can be simple. I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.

Your system is not well thought out and would not handle dependencies / parallel startup very well. However, generally speaking shell scripts should definitely be the exception: executable configuration files are a bad design. If you must use arbitrary scripts, then you should abstract the common elements and reduce the part that must be expressed as executable code to the bare minimum. Have sane defaults, and an easily-reviewed common subset of functionality, make the simple things easy, and stay out of the way of anyone who really really needs a programming language and shell in order to start a program.

Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard.

The important part of systemd is actually managing processes and services, startup is where most of that happens, but it's not the driving force of systemd. The reason why systemd exists, and the reason why it isn't portable, is because of cgroups, which are a feature specific to the Linux kernel allowing for real process management. In non-systemd Linux, daemons must carefully communicate through special files what they are doing, or the OS is not able to determine anything about the service. There is a complicated process which every process that wants to daemonize must follow, and the only thing that makes this remotely sane is longevity. Solaris and OSX have both separately replaced SysV init.

I have read that FreeBSD has taken the strategy of using essentially a library of common things that init scripts might want to do, but for the general case having this library be written in an interpreted language gains little.

Comment: We have cookies (Score 1) 312

by Tenebrousedge (#48185637) Attached to: If You're Connected, Apple Collects Your Data

...I pretty much loathe the command-line. Text UI be damned! To the depths of Mount Doom!

If you only knew the power of the dark side!

Bash is not the most fun programming language, but CLIs (as distinct from TUIs) are the easiest way to interact with a computer system programmatically. There is such thing as graphical programming, but...ew. On the one hand, you've been able to install and use Linux for about a decade now without ever seeing a command line. On the other, the Internet would not exist if it weren't for CLIs.

I think we're gonna need to confiscate your geek card.

Comment: Can I have some of what you're smoking? (Score 1) 331

by Tenebrousedge (#48181143) Attached to: No More Lee-Enfield: Canada's Rangers To Get a Tech Upgrade

A land-grab in the ocean? The Battle of Ellesmere Island?

I think there's about as much chance of having a small arms conflict in the Arctic as there is of Putin invading Greenland riding a polar bear. What exactly do you envision? Canadian troops invading Novaya Zemlya? The Arctic is unpopulated in a way that is difficult to describe. There is no one to shoot, and even getting there is a huge logistical problem. I'm pretty sure you've never been to the Arctic, but for the sake of argument, is there any basis to these ideas of yours?

Comment: Re:Google has a love/hate relationship with JS (Score 1) 194

by Tenebrousedge (#48179879) Attached to: JavaScript and the Netflix User Interface

I was wondering about that, but I didn't manage to find any information. Do you have a link handy? And maybe information about the differences between Google's stuff and ARChon?

When I said that it hadn't caught on, I meant that other browser vendors were not interested in implementing NaCl.

Comment: Google has a love/hate relationship with JS (Score 1) 194

by Tenebrousedge (#48178021) Attached to: JavaScript and the Netflix User Interface

Isn't that more or less the idea behind NaCl/Native Client? It doesn't seem to have caught on. For that matter, there was also ActiveX, and the best that you could say about it is that it had a flawed implementation.

Chrome also just added a runtime for Android apps, which seems to handle at least some simple apps at native speed on my chromebook. I suppose that's a java runtime of some sort?

I know that there are many wonderful things done daily in JS, but I really would prefer another scripting language.

Comment: Wayland exists because X is bad at what it does (Score 1) 225

by Tenebrousedge (#48173205) Attached to: Lead Mir Developer: 'Mir More Relevant Than Wayland In Two Years'

Have you seen the videos about why X is fundamentally broken? Did you read the fine article? There are a lot of horrible flaws in X that cannot be fixed short of a rewrite.

I get the impression that you haven't done any research into this issue, and are dismissing it based on a stereotype. Familiarity breeds contempt, and I am sure that to some degree the trend you identify exists. However, devs don't usually go that far out of their way to make work for themselves just on a whim, and I do expect them to actually be able to identify flaws in their software. Also, you should not assume that just because something is 20 or 30 years old, that it does not have major flaws. Even ignoring Shellshock, there's a lot of justification for replacing X with something else. If you believe otherwise, maybe you can pop over to the Wayland dev channel and explain why they're all wrong and that they don't need to be spending time on it.

Comment: Cgroups (Score 2) 519

by Tenebrousedge (#48173139) Attached to: Debian Talks About Systemd Once Again

The reason why systemd exists, and the reason why it isn't portable, are the same reason: it depends on a feature specific to the Linux kernel.

It's not up to the systemd developers to write kernel features for other OSes. If there's an "anti-standard" it's the kernel, not systemd. If the rest of the Unix world wants to implement something similar then I am sure it could be made part of a standard eventually. Until then, you've wasted space typing.

This screen intentionally left blank.

Working...