Hacker News new | past | comments | ask | show | jobs | submit login

It's like people don't even try to learn how it works

It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.




You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration.

To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.


That's a really good point, thank you. I've never really thought about it that way; e.g. the registry is something you should sort of treat as an opaque blob of state (like a smalltalk image?) that you just mutate over time programatically, rather than as a declarative set of configurations to bring the machine to at any time.


> You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration.

That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).


After coding for several years, the two aren't all that different.

I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX.

Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.


I think you have it backwards. Sysadmins are not the ones arguing in favor of "the one true way". That is squarely in the newer breed of developer/admin devops hybrid that the systemd camp is pandering.

For sysadmins the nix way of text in and text out allow systems to be as simple or complex as they need to be, because parts can be swapped, added or removed as needed.

The kernel don't care what your initial process is (you can for instance point the Linux kernel straight at the sh binary and be presented with a root shell the moment the kernel is done getting the hardware up and running), and the programs you want to run don't care either.

Thus you can run nix on anything from a dinky single core SoC to a warehouse sized compute cluster.

But systemd is pandering the latter while giving the former the middle finger. This by ignoring the text in text out loose bindings that has been the core of *nix.


I'm not trying to be facetious...What part of X11 matches the text in/text out -- small programs that do one thing -- mode? Even Linus says that "model" doesn't really apply any more.

Maybe systemD and it's author's are whatever...I think that the CoreOS people are demonstrating that programmatic administration is the best model for massive scale. That's my only point.


X11 may be an odd duck out in the nix world, but then i started as a way to put graphical terminals on mainframes.

As such the server end started out being a beast all its own...

Still more flexible than systemd though, as i can run a X server on, say, Windows to get the UI of a program running any kind of nix out there.


That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :)

I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system.

With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source

(I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)


Wow. Before I start...that's cool that you are using CE. What are you using it for? (If you don't mind and have a minute.)

I get what you are saying. I don't think that the programmatic model of administration works for running something like PeopleSoft, right? You use large hosts that are very special and benefit from the traditional admin model. It's very much a "pet"...where the CoreOS model is more "cattle".

I'm more ambivalent about access to source as long as there is good documentation and debugging tools. I'm not going to fix a kernel bug at this point in my development. Maybe one day...


Also, to be fair...someone has to write code to turn the text config file into bits in memory.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: