Article is badly formated on mobile.
The Collapse of the Unix Philosophy
351–360 of 616 posts
Re: The Collapse of the Unix Philosophy
#352Earlier quoted context omitted.
Hence why UNIX on mobile is a Pyrrhic victory, as iOS, Android, ChromeOS rely on Objective-C, Java and JavaScript runtimes and their respective frameworks, just with good enough support from POSIX, that could be replaced by what is expected from any ANSI C implementation.
There is no Objective-C "runtime". (Well, there sort of is, but it's just a library, not a heavy-handed thing like you're thinking of). Unlike Android, iOS apps are just normal compiled ARM machine language binaries executing natively. Yes, you have to use their APIs in order to write graphical programs, but the same is true on any OS with a GUI system. It's possible to write iOS apps in pure C if you want to. Sure,…
Of course there is a runtime, even C has a runtime.
All programming languages, other than Assembly have runtimes.
From the point of view of compiler design a runtime is everything required to support a programming language execution.
On C's case, calling main (), floating point emulation, initializing globals, parallel code execution, thread locals.
Re: The Collapse of the Unix Philosophy
#353Earlier quoted context omitted.
There is no Objective-C "runtime". (Well, there sort of is, but it's just a library, not a heavy-handed thing like you're thinking of). Unlike Android, iOS apps are just normal compiled ARM machine language binaries executing natively. Yes, you have to use their APIs in order to write graphical programs, but the same is true on any OS with a GUI system. It's possible to write iOS apps in pure C if you want to. Sure,…
Of course there is a runtime, even C has a runtime. All programming languages, other than Assembly have runtimes. From the point of view of compiler design a runtime is everything required to support a programming language execution. On C's case, calling main (), floating point emulation, initializing globals, parallel code execution, thread locals.
Did you read the very next sentence?
Re: The Collapse of the Unix Philosophy
#354The most interesting thing I learned from this article is the sprintf() pre-compiler (http://blog.kazuhooku.com/2014/10/announcing-qrintf-and-qrin...). That's awesome.
The rest, well, its a helpful check on over enthusiasm to be familiar with the shortcomings of UNIX. By dint of its popularity, diversity and long lineage, UNIX and its derivatives are particularly rich in warts. Yet, I think it must be true of all real-world operating systems with a long life that cruft, workarounds and ossified bad ideas accumulate.
Re: The Collapse of the Unix Philosophy
#355Some of my primary beefs with Unix, stated more concisely than the rambling article: 1) Text is for humans, and is generally incomprehensible to machines. Encodings, arbitrary config file formats, terminals, etc, are all piles of thoughtless one-off hacks. It's a horrible substrate for compositing software functionality, through either pipes or files. 2) Hierarchical directory structures quickly become insufficient.…
1. Binary formats are great, until they break. I would take plain strings configuration over Win95 registry any day. Actually, I'd take plain text conf over Win10 registry any day also. How do you transfer your (arbitrary) program settings from one computer to another? I can tell you how on Unix. How would you on windows? 2. / based filesystems are head and shoulders better than Windows. Why should moving a directory…
I'm pointing out flaws in Unix. The fact that other environments have different/worse flaws than Unix doesn't make Unix's flaws not flaws. The point is to think outside the box and stop being constrained by arbitrary decisions of the past, be they from Unix, Windows, or wherever.
See my other response below about the text issue. It's not about 1 program having a text file, it's about managing all text files on your system that sucks, especially when you want them to interoperate in terms of data or automation, or even have some sort of consistency in expectation between them in human terms. The term "Text" implies data that is unspecified and unpredictable; in encoding, syntax and semantics; across various instances of it.
Re: The Collapse of the Unix Philosophy
#356The Collapse of The Blog Philosophy.
Re: The Collapse of the Unix Philosophy
#357Earlier quoted context omitted.
>Windows 10 already sorted out the filename limitations. No, it hasn't. Filenames are still case-insensitive (and in a terrible way, where it seems to remember how they were first typed but that can never be changed), backslashes are still used for path separators instead of escaping characters, and the worst of all is that drive letters are still in use, which is an utterly archaic concept from the days of systems w…
Windows NT (the core OS) suffers none of those problems. The Windows (Win32) environment suffers those limitations. It also suffers 20+ years of strong binary compatibility, broad hardware support, and consistent reliability that systems of similar class (e.g. Linux desktops) can't match. If it makes you feel any better, drive letters are a convenient illusion made possible by the Win32 subsystem; NT has no such conc…
> The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need.
Another case in point: it allowed MS to write a layer on top of the NT kernel to run unmodified Linux binaries. (Windows subsystem for Linux).
Re: The Collapse of the Unix Philosophy
#358Earlier quoted context omitted.
We run systemd on 512mb celerons no problem...
I'm sad that 512mb is now considered a small amount. I've got a couple of systems in my drawer that have <128mb.
I still have my 75 MHz Pentium 12MB EDO RAM laptop running Windows 95 and holding my old BBS sitting in my drawer. Battery is shot but plug it in and it still works.
Re: The Collapse of the Unix Philosophy
#359Some of my primary beefs with Unix, stated more concisely than the rambling article: 1) Text is for humans, and is generally incomprehensible to machines. Encodings, arbitrary config file formats, terminals, etc, are all piles of thoughtless one-off hacks. It's a horrible substrate for compositing software functionality, through either pipes or files. 2) Hierarchical directory structures quickly become insufficient.…
1. Binary formats are great, until they break. I would take plain strings configuration over Win95 registry any day. Actually, I'd take plain text conf over Win10 registry any day also. How do you transfer your (arbitrary) program settings from one computer to another? I can tell you how on Unix. How would you on windows? 2. / based filesystems are head and shoulders better than Windows. Why should moving a directory…
> How do you transfer your (arbitrary) program settings from one computer to another?
Export/import the relevant registry keys, just as you copy/overwrite the relevant config files. If you can't find the reg keys, what makes you think you can find the config files?
You don't even need to do anything for your roaming user profile to follow you on a windows domain! I couldn't tell you how to accomplish the same on Unix.
> Can I do the same on Windows?
I routinely (ab)use mklink to keep the path identical despite moving things between disks or onto remote shares. Different subdirs within C:\Program Files\ are often on separate disks - just copy, paste, and mklink. I haven't run into an application that complains (although I have had installation scripts botch things on rare occasion by deleting my mklinks.)
You can also do unix style mount-a-disk-in-an-empty-directory if that's your jam, and have e.g. C:\SSD. For the GUI, see the "Disk Management" tool - RMB the partition, "Change Drive Letter and Paths...", "Add...", (*) "Mount in the following empty NTFS folder:". Powershell can use WMI: https://learn-powershell.net/2012/08/10/locating-mount-point...
Re: The Collapse of the Unix Philosophy
#360Earlier quoted context omitted.
I had much the same reaction. I learned Unix on a PDP-11 running sixth edition AT&T. I was also using the University's UNIVAC 1108 and the elegance, simplicity and orthogonality of the Shell vs the EXEC-8 command language was a joy to behold. Sure, there is much about Unix that could be better and I sometimes regret that Plan 9 didn't succeed more. But it's like Kirk said to Saavik, "You have to learn WHY things work…
I wrote my own version of Make for VAX/VMS and MSDOS, back in 1983 or so. I hated the tab mechanism of the Unix make, so I didn't use it, and none of my users (of which there were apparently thousands) ever complained. I got a few "thank you"s for it. TAB was a stupid choice even in the 1970s.
Tab are actually more eco-friendly than space.
Just think of the energy lost sending 4 characters instead of 1 in every uncompressed json/xml actually moving around because lazy people don't mind suppress them before sending it over the network...