Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Congress Can't Make Asteroid Mining Legal (But It's Trying, Anyway)

CaptnZilog Re:Jurisdiction (213 comments)

I would say the same thing, but there are several countries that can effectively impose their will anywhere within the Moon's orbit and a handful that could manage anything within the solar system. That said, having navigational control of a big rock on the edge of a gravity well may prove to be a hefty bargaining chip.

The Moon is a Harsh Mistress. :-P

about a week ago
top

Microsoft Agrees To Contempt Order So It Can Appeal Email Privacy Case

CaptnZilog Re:About Time (123 comments)

I've used your analogy before. And USA law is that the USA corporation is legal obliged to instruct and take measures to get the data from the UK subsidiary. Nothing is changing here this has always been the case.

Which is, in effect, saying that MS then would have to take their UK subsidiary to a UK court to get a ruling, spending their own money taking themselves to court, in essence. That really should be for the US courts (prosecution) to take up with the UK court, shouldn't it? I mean, the whole concept of "me suing myself, and having to hire *both* prosecuting & defense attorneys" is ludicrous...

about two weeks ago
top

Microsoft Agrees To Contempt Order So It Can Appeal Email Privacy Case

CaptnZilog Re:About Time (123 comments)

No, the evidence is not the property of a US company. The evidence is the property of a US citizen and is being held by a foreign subsidiary of a US company and is, therefore, exactly like the hotel example.

The world really would be simpler if we stopped trying to define how information on computer is the same as information on paper in some circumstances and different in others and just say that correspondence is correspondence, personal effects are personal effects, etc.

Which is, I would think, what MS is trying to do... get the courts to rule on it, one way or another, from the highest court possible.

about two weeks ago
top

California Tells Businesses: Stop Trying To Ban Consumer Reviews

CaptnZilog Re:hmmmm (275 comments)

NDAs are to cover technology or "trade secrets" - writing a review for "peppermint Coca-Cola" (making something up) saying "it sucks moose balls" isn't revealing their 'recipe' for making it or anything secret, anyone can buy a can and make their own judgement.

By the same token, even if I enter an NDA with a company to, say, integrate their technology into a product - saying "these people are a PITA to work with and I would never want to deal with them again" isn't violating the NDA on their technology.

Now... I could see perhaps if you entered into a deal with say Rossi and the "eCat" cold fusion nonsense, that saying "they're a fraud, the technology is a hoax" might perhaps be a gray area - but still, as long as you're not revealing their 'secret catalyst' or the actual (non-) functioning details of the device, you aren't really revealing their 'secret' technology?

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:Er? (314 comments)

The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone

Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.

So you're "fixing" a bad application by changing the OS?

Apparently that's the "preferred solution" now... to me it seems to make far more sense to fix the application (BackupExec) to work the way it should, but that type of "logic" apparently doesn't apply to the systemd people who think that the "proper" way to fix that is to write a complex init system replacement and continue to allow people who write shitty service/daemon code to continue writing crappy code.

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:/etc/inittab (314 comments)

and rc.d it's so simple.

It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....

Sounds like those issues are implementation based.

Yeah, sounds like some work needs to be done fixing the init scripts rather than writing a whole new init system to allow people to keep writing crappy scripts?

and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and.

Ok - well your talking about desktop stuff here, which is an interesting perspective that I didn't really consider, however I still think that is doable in inittab with much less effort. rc is only a runlevel solution, whereas inittab would be more relevant to desktop. I don't need to keep track of the process and it's children because init can maintain the parents state for me - if the parent isn't signalling it's children then we are back to implementation issues again.

Yup, instead of tackling the real problem - poorly written services - their "solution" is to try to write a new init system to allow crappily written services to be tracked/"controlled", ignoring the fact that the crappy modular services should be rewritten.

I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.

jeeez. I'm just trying to figure it out. I'm not being a jerk about it, I'm trying to gauge other peoples experiences. I don't give a fuck about init if systemd is better - it's just another technology. But if it is better than shouldn't it be immediately apparent *WHY* it is better?

Yeah, and I don't see as it "fixes" anything other than adding a lot more complexity to "fix" things that it shouldn't have anything to do with.

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:/etc/inittab (314 comments)

It could be argued that such things are simply not the responsibility of the init system. I think that is where much of the complaints about systemd come from, the perception that it is taking the roles of other things and folding them into itself. Given how it has been expanding to include more and more services and has increased coupling, they kinda have a point. Many see systemd as solving problems that are philosophical in the first place as opposed to practical.

"One ring to rule them all."

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:/etc/inittab (314 comments)

What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?

If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.

Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:/etc/inittab (314 comments)

It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.

It's not supposed to - a *properly* written service would/could/should keep track of it's own processes, that isn't something init was ever supposed to do (be the 'micro-manager' of everything). If run the rc script to stop a service, and it doesn't stop all the associated processes, that is *NOT* a "problem with init", that is a problem of a poorly written/debugged service, and the code for the service should be fixed - not a whole new massively complex init system to "handle" it (or, in simpler terms, to continue to allow the people writing services to write shitty code because now "systemd will handle it").

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:Huh? (314 comments)

You'll also find that systemd is indeed quite unix-like......It's about consolidation of functions into one implementation

ok, you failed to understand the unix way

Bingo. Sums it up quite nicely.

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re: ntp is the line in the sand (314 comments)

You know that was a joke, right?

Daemonhostd is clearly a play on Windows Service Host.

Well, at least I HOPE it was a joke. With systemd, I'm not sure anymore.

You mean "daemonhostd.exe" right? ;)

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:Stupid, stupid stupid (314 comments)

Go tell that to the GNOME dev, who adopted systemd and now require it on all platforms running Gnome.

Why in God's name would you want to infect well designed OSs with Gnome?
That's unbelievably stupid.

I gave up on Gnome long ago.

about two weeks ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

CaptnZilog Re:Engineering for reliability, not philosophy (314 comments)

That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1.

I will be clear that I am not a seasoned linux sysadmin; I know bits of Linux, I can manage a small installation, but Im definately not an expert. Im also not a seasoned programmer; I understand programming.

However I have had experience with a lot of badly written services on Linux where I've had to decipher the init scripts, or figure out why "service XX stop" doesnt actually stop the service, whatever stdout might claim.

It seems to me that the approach you are advocating works really well in a world where badly written services simply die out due to people rejecting them; in reality you have badly written services all over the place that get screwed up all the time. Your philosophy could be extended to say "we'll also have the kernel just manage cpu, disk, and memory, and leave handling the filesystem up to individual programs." Which works, as an engineering principle, but in the real world you will end up with filesystem corruption on a daily basis because you are causing the entire system to have a net increase in complexity.

From what Im gathering, systemd increases the base system complexity, but will (over time) ensure that those complex bits are stable (much like building FS support into the kernel). On the upside, it allows all of that complexity to be removed from all of the million other packages where 'building a stable init script" may have been priority 99 out of 100, and now they simply dont have to worry about that.

I see, so you are blaming the current minimalistic init process, that hasn't had any known/major bugs for decades really, for "badly written services all over the place"? Wouldn't that, instead, be something to push more for "better written services" about, rather than increasing the complexity of the init process?

Yes, as an *experienced* sysadmin (28yrs of Unix, from Edition7/earlyBSD to Linux/SysV, on everything from "big iron" to PC servers) I've seen poorly written start/stop scripts that don't do what they should, don't handle 'failure to stop' properly, etc. I've almost always been able to deal with it manually, in the rare cases it happened (HPOV was one of the worst, randomly left stuff running) I could fix it manually w/o a reboot, and if needed I could fix the script fairly easily (or submit a bug report to the vendor - even though they rarely fixed things like that very promptly). I certainly didn't blame the fact that some programs rc script was poorly written, or its processes were poorly written pieces of crap, on the init process. Under *any* Unix derivative I've worked on, well written services rarely needed a restart in the first place.

If the battery in your car dies, do you also launch an engineering team to redesign an entirely new car powered by a suitcase sized nuclear reactor, with all the increased danger that could involve if the 'unforeseen' happens, or do you just replace the faulty battery?

about two weeks ago
top

DMCA Claim Over GPL Non-Compliance Shuts Off Minecraft Plug-Ins

CaptnZilog Re: ELI5 please (354 comments)

It may be an unpopular viewpoint, but this is why business is leery of the GPL and 3rd party contributions. Mojang should have been a little smarter before they acquired the toolkits and developers so they knew the ramifications of their purchase. At this point, it sounds like Mojang is being extorted since the code was never properly license in the first place.

Bingo. A lot of companies avoid GPL for just this reason.

about two weeks ago
top

DMCA Claim Over GPL Non-Compliance Shuts Off Minecraft Plug-Ins

CaptnZilog Re:ELI5 please (354 comments)

You hit on one of the key words, "cleanroom". No code was contributed to Bukkit by people within Mojang with access to their internal repo. So the decompiled version is GPL while the internal version is not, thus no violation.

No, the decompiled version is still Mojang's code, it's not (and cannot) be GPL just because they decompiled it - any more than you could decompile a copy of MS Office, and say that the source to DecompiledOffice is now GPL.

They *stole* Mojang's MC code, in essence, by decompiling it and distributing it. Mojang was nice enough not to take them to court over it - but that doesn't mean the code is suddenly GPL.

about two weeks ago
top

DMCA Claim Over GPL Non-Compliance Shuts Off Minecraft Plug-Ins

CaptnZilog Re:ELI5 please (354 comments)

(From GPL V3)
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

I would venture to say that the mod is not an "extension of a GPL3 covered work", in fact quite the reverse - it's an extension of a non-GPL work.

about two weeks ago
top

DMCA Claim Over GPL Non-Compliance Shuts Off Minecraft Plug-Ins

CaptnZilog Re: What the heck? (354 comments)

I don't see how the situation creates a GPL violation. It sounds, in fact, like the copyright that is violated is the copyright Mojang holds for Server, and Mojang has been kind enough to not press charges.

Sounds like it to me, they decompiled/reverse-engineered the Mojang *non-GPL* code, and Mojang was decent enough not to try to take them to court over revealing their own proprietary code. A lot of companies would have sued their butts off.

about two weeks ago
top

Could Tech Have Stopped ISIS From Using Our Own Heavy Weapons Against Us?

CaptnZilog Re:The first rule of technology (448 comments)

Right, the best way to prevent sophisticated American weapons from ending up in the hands of ISIS would have been to not hand them over to an incompetent sectarian asshat like Nouri Al-Maliki, the proper way to prevent that from becoming the only option would have been to not start a stupid war in Iraq to boost Halliburton stock prices, this in turn brings us to the most workable way to prevent America from starting a stupid war in Iraq in the first place which would have been to not elect a cheerleader for president.

Bill Hicks on George H.W. Bush & the military industrial complex

about two weeks ago
top

You Got Your Windows In My Linux

CaptnZilog Re:Troll much? (613 comments)

Especially in the server world. The OS boot time is a fraction of my server's boot process. Starting out, you've got POST with RAM tests et al. The RAID array spins up and does its dance. Maybe IPMI gets in the mix. The NICs might have their own prompt for configuration changes lasting a few seconds. And sometimes the BIOS decides to give a detailed list of events with a ten second countdown (bypassable with a keystroke). Then some particularly silly BIOSes complain for a few seconds about a lack of keyboard. Finally, the MBR is touched. systemd will never speed up the slowest part of the boot process, so it's useless for that purpose in a server environment.

Yeah, in all honestly OS boot time has never been an issue for me on startup - it's all the other stuff... the BIOS memory test on a 64GB machine, followed by by probing all the cards for their BIOS's and delays for disks to spin up, etc. When the machine takes 5 minutes to get past the BIOS/hardware level stuff, the 30-60 seconds it takes to actually boot Linux up to a login prompt (especially w/o X setup for logins) is minimal.

about two weeks ago
top

You Got Your Windows In My Linux

CaptnZilog Re: What's wrong with Windows Server? (613 comments)

No it doesn't. You need the X client libraries installed, but no X server needs to run on the server.

Correct. The X-server is effectively the "display side" of the equation - you'd run it on your desktop/laptop to connect to the 'client' (your Linux/Unix server).

Nobody in their right mind really wants to be running an X-*server* on their actual Linux/Unix server - usually the server doesn't even have a real display on it anyways (and it's been years since I've really looked, but all the datacentrer-type KVM stuff I've seen sucked at even handling 1024x768 for 100's of servers - although my 8-port KVM on my desk works ok for the 4 boxes I have hooked up to it - but monitor/cables/pc's are all within 8 feet of each other).

about two weeks ago

Submissions

CaptnZilog hasn't submitted any stories.

Journals

CaptnZilog has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>