What's so cool about the UNIX philosophy? What would a heavy UNIX philosophy operating system look like? What is the most heavy UNIX philosophy operating system out there at the moment, besides UNIX itself?
Define your terms, unless you like being confused by the answers.
The answer is always Plan 9, but the reasons vary depending on what you think constitutes the Unix philosophy.
How does the GUI work in Plan 9? I can't imagine a GUI system that works in a way UNIX puritans would approve of, though maybe that's because X has warped my mind.
Name:
Anonymous2013-02-09 20:25
IMAGINE AN OS WHERE YOU CAN DO ANYTHING YOU WANT
AS LONG AS YOU COMPILE THE SOFTWARE YOURSELF
AND RUN IT ON A VT220
THAT'S THE UNIX WAY
Name:
Anonymous2013-02-09 20:35
There should be a documentary on Unix.
Name:
Anonymous2013-02-09 20:40
>>4
Three button mouse, all the apps happen to be ACME. Every mouse button does one thing in ACME: select text, execute command and load file. I think Oberon had a similar GUI workflow.
>>1
The big thing about UNIX and Unix-like systems is the insistence on decomposing the entire system into small components with a lightweight interface. You can contrast this with IBM (or to a lesser extent, Windows) systems where programmability requires interfacing with a large, inflexible framework of some kind. On UNIX, you just reach into the guts and pull out what you need. Some people will emphasize text orientation as a major component of this, but it's really just the way interaction is typically enabled.
>>4,5
Yup. The big evolution is that you can easily yank text around both the shell and the editor to mung and re-execute. There's no more struggling with screen or the X clipboard to move text somewhere for a one-off job. All your interaction with the system is still defined by the text, but you now have less friction involved in designating what text to use.
Name:
Anonymous2013-02-09 21:27
>>7
I understand how it works from the user's point of view (and I think it's pretty neat, actually) but how is it organized? Graphical objects aren't text or files. You can't pipe them or manipulate them in the same way you can with everything else in UNIX (or am I wrong?)
>>8 struggling with screen or the X clipboard
I also wish they'd implemented that better. The X clipboard feels too ``meta''.
>>9
Interactive data like GUIS or network devices that postdate Unix are really where it falls down, hard. Every system in common use gave up on providing a unified model for these; you have to use an API of some sort (Xlib, Berkeley sockets) to talk to them.
Plan 9 ``solves'' the problem by allowing any component (not just the kernel!) to expose itself as a file system. So, for example instead of doing an API call to change the contents of a window you can just open the file that represents its contents and write to it.
>>14
LLLLLEEEEEEEEEEEEEEEEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLLLL
>EGIN LE SAGE!
>LE FAGGOT
>EGINGOINGWINZIMSIN GRO!!!!! XDDDDD
Name:
Anonymous2013-02-10 12:37
>>10 Plan 9 ``solves'' the problem by allowing any component (not just the kernel!) to expose itself as a file system. So, for example instead of doing an API call to change the contents of a window you can just open the file that represents its contents and write to it.
That sounds like a good idea since the tools and ``interfaces'' are already there, but it seems kind of superfluous. On the back end of things, wouldn't it just be running some system call or library function I could have ran directly instead of accessing through a file?
Name:
Anonymous2013-02-10 13:26
>>16
nigga the only api u need is
open()
read()
write()
flush()
close()
ioctl()
Name:
Anonymous2013-02-10 13:29
Powershell.
Name:
Anonymous2013-02-10 13:31
>>16
Perhaps, but that way it's guaranteed standardisation across the whole system. Consider how different image libraries each have different interfaces - with plan9, this would not be the case. You'd just choose an image format and the resulting library/file operations would be identical.
>>21
Not really. Compilers optimise stuff, you know. And file operations don't touch the filesystem once they're established.
If speed is your concern though, what are you doing using an academic's operating system?
Name:
Anonymous2013-02-10 15:15
>>22
Hey fagshit, we have highly specialized and zomgoptimized image formats and functions for a reason. If you want a hard drive full of BMPs or some other format that is easy to edit ``as is'', be my fucking guest.
>>23
Do you understand what you're talking about?
Plan 9 proposes that libraries expose themselves through virtual filesystems, not unlike /proc, /sys, /dev...
The actual implementation will be identical to the same library exposing itself through dynamic linking and #included headers.
I don't know what the fuck your argument is, but it certainly isn't relevant and it certainly doesn't follow from the one you previously put forward.
>>16,17
Bloated APIs are the problem, not the solution. Look into the situation we now have with networking system calls and ioctls in the Linux kernel - it's not pretty, and if people keep adding things it will become a nightmare.
>>22
Having a uniform interface to differing implementations is sort of the whole point of software design, you know. The inner loop of of an image processing tool is not going to be the 9fs it exports to the system.
>>18,20
People need to stop talking about Powershell as if it's competing with Unix shells. The name of the thing is just [Ww]indows? dressing, and misleading. You aren't supposed to use Powershell interactively (really, has anyone tried? It's horrible). Its real game is competing with admin scripts written in Perl or Python.
>>27
I was trying to address what I perceived to be >>21's concern about the speed of opening a "file" vs. calling a function from a dll. I didn't know he was going to turn out batshit in >>23
>>28
If a lot of data is exchanged through the file server, it's going to be significantly slower because you must context switch and wait for the server to parse the data every time. X clients must already do this when they deal with the X server, though, so if you're using a Unix system already there's no reason you should object to this. Windows style (GDI) is another matter...
Name:
Anonymous2013-02-10 16:50
>>19
So the filesystem would make available to me all the functions in libpng?
>>31
You might mmap for direct rendering if you're running the window client and the server on the same machine. Plan 9 was designed in the early 90s, so I believe it would predate the addition of direct rendering to X. Plan 9 stresses network transparency so heavily, I doubt the developers would have had much motivation to use it.
Checking the man pages - it appears Plan 9 doesn't have mmap anyway, so the discussion is moot. Evidently the developers don't want you doing anything fancy with the page tables on Plan 9 - you get shared memory IPC based on segments and that's it.
In the absence of the ability to redirect output and input, a still clumsier method would have been to require the ls command to accept user requests to paginate its output, to print in multi-column format, and to arrange that its output be delivered off-line. Actually it would be surprising, and in fact unwise for efficiency reasons, to expect authors of commands such as ls to provide such a wide variety of output options.
>>35
The question then becomes, why hasn't someone replaced GNU ls with some combination of ancient Unix ls and a shell script. If you can answer that, you understand why `The UNIX Philosophy'' isn't the solution to every problem.
Name:
Anonymous2013-02-15 13:42
>>36
Because then GNU wouldn't have the market share from its HIP, MODERN FEATURES that try to make you depend on them like crack.
Basically, the same reason teenagers install Instant Messenger Plus: Extra Spyware Edition instead of Instant Messenger.
>>36
What? There are a lot of Linux distros that don't use any GNU software at all.
Name:
Anonymous2013-02-15 16:20
>>36
The BSD systems have minimal features compared to GNU.
>>37
Is it really GNU's fault for sharing software that people actually use? Remember, GNU's goal is about making a full featured system, not about following the Unix philosophy.
Name:
Anonymous2013-02-15 16:30
>>39 Is it really GNU's fault for sharing software that people actually use? Remember, GNU's goal is about making a full featured system, not about following the Unix philosophy.
Of course. It's a noble goal and I wish them luck, but I disagree with their methods.
At times it can be harmful, e.g. when people, systems and software expect some nonstandard GNU extension even though the POSIX equivalent would do. People who have to de-autotools software or maintain BSD ports have my condolences.
>>37,39
You're missing the point. It's not just the GNU project that has done this. The symptom of bloating shell utilities with options instead of layering scripts over them dates back to BSD.
The underlying disease is the (Bourne) shell - it just sucks so badly that it was easier for the feature implementers to extend the C code of the tools themselves. Think about that - what is the point of even having a shell language if it is harder to use than a systems language?
>>39
The thing about not following the Unix philosophy is that you never realise how good of an idea it is until you do, and then it's too late and the best you can hope for is to shoehorn it back in one shitty piece at a time. Just look at how Windows has evolved since the early '90s.
This is also why I wish Lennart Poettering would get hit by a car.
>>45
The POSIX subsystem only supports POSIX.1 and has been deprecated since Windows XP. Interix is only available on the most expensive Windows distros, and is badly broken to boot.
Powershell is a bad joke.
>>49
Someone doesn't actually know what POSIX.1 is.
Of the pre-1997 standards, most users would only really care about POSIX.2. Developers would care about POSIX.1b and especially POSIX.1c at least as much as about POSIX.1.
>>48
Because Windows and the NSA have abused their power on several times, even today. Did you read about that recent DNS rootworm? Yeah, Windows made for NSA testing.
> “They didn’t hack Microsoft, no-one has broken into Microsoft, but by repurposing the certificate and modifying it with unknown hash collision technologies, and with the power of a supercomputer, they were able to start signing any program they wanted as if it was from Microsoft. If you combine that with the mechanism they were using to spoof MS Update server they had the crown jewels,” Hypponen said.
Well shit, if the NSA can't even trust me, who can they trust? And if they can't trust anyone, doesn't that just mean that they simply aren't trustworthy themselves..? Why else trust no-one..?
It would be easy to prove, in a sense, all they'd have to do is de-classify everything... But that is asking the impossible, in another sense, Because What ?! They Are Not Trustworthy... And the Truth would only prove that a thousand times over..
You wish for me to trust you, but how can I, knowing you aren't worthy to begin with..?
What were you expecting to find..? I am not you? Suprise! ^^
Name:
Anonymous2013-02-16 21:53
>>57
A backdoor isn't going to be as obvious as if (is_fbi == TRUE) { ... They are usually intentional ``bugs'', e.g. an intentional overflow exploit that allows the user to run malicious code.
You can't just ``read the source code'' and infer these things. The only effective method is auditing. Hence all the drama with OpenBSD: http://marc.info/?l=openbsd-tech&m=129236621626462
Name:
Anonymous2013-02-16 23:19
>>64
That's why they push languages like C and C++. If we all used a type-safe language like Haskell or Algol 68, there would be full memory protection with no need for separate address spaces. Buffer overflows would be impossible.
>>64
Sir, I have not only read the source code, I tested on multiple standards I am required to do as my job, and still have not found one on a vanilla installation of FreeBSD. And I am not talking about the obvious holes that are on inetd and BIND (programs) on every OS, including the ones ported on Freebsd.
The drama on OpenBSD was from non-auditors, and the closest I can find, again are the obvious BIND security hole, esp. inetd.. You are welcome to make your own versions although, or use others than the default. We make our renditions of the defaults.
>>65
You are correct sir. We use chicken-scheme to type check our C code, and the binaries as well. We must compile back to C to maintain the source portable enough for multiple servers with different architectures. We also have a legacy standard we have to follow.
>>68
Small donations from and interested party does not mean the project/product has vulnerabilities. You have the freedom to review the code and audit it.
Sir, I have not only read the source code, I tested on multiple standards I am required to do as my job, and still have not found one on a vanilla installation of FreeBSD.
Are we just supposed to take your word for it? The word of an Anonymous poster on a shiitchan BBS? Your words don't have any more weight than the ones who say that there are backdoors. The only way to check is to read the source yourself.
I'm not the person you were talking to, as this is my first post in this thread, but please refrain from assuming that we're all going to believe you, as opposed to just thinking that you're full of shit. I sincerely doubt you've read through the entire FreeBSD source tree.
>>70
No, I am telling you to read and audit any code yourself. I do for a living. I do not care if believe me. Just be proactive with what do, that is all.