341–350 of 616 posts
Earlier quoted context omitted.
Yes, yes, yes. I'm saddened that tabs have essentially 'lost' - they seem to me in every way superior to spaces, but I would never use them in a new project simply because it would be likely to throw off others, and perhaps tooling. Github, for example, does not play nicely.
Spaces are superior to tabs in only one (important) way: They're a constant width.
Earlier quoted context omitted.
To argue for the OP, consider the case of passwd being parsed on every system call. That is simply sub-optimal. (It also seems exaggerated to me, and feels like a prime candidate for caching). Further, there is an immense value in GUI based systems: discoverability. On a GUI, you can learn how to use a program without ever consulting a manual just by inspecting your screen. This addition is what brought the computer…
> To argue for the OP, consider the case of passwd being parsed on every system call. That is simply sub-optimal. passwd is not read every system call and anything that is read frequently is almost certainly in the fs cache. I got about 3 assertions into the article before I decided I had enough of that bullshit.
This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it. I feel so privileged to read this random guy's blog, and it's terrific that he eschews inflating his ego so well.
>How to touch all files in foo (and its subfolders)?
find foo -print0 | xargs -0 touch
find foo -exec touch {} \;
I think it's very telling that the author consistently refers to directories as "folders". All of UNIX makes perfect sense if you are using UNIX for UNIX. If you're doing other things, like abstracting to "folders" and so on ... I am open minded and can see where it starts to fall apart a bit. But I use UNIX for the sake of UNIX ... I am interested specifically in doing UNIX things. It works great for that.
Asking not to make a point but because I genuinely don't have any clue: what is the distinction in your mind between a "directory" and a "folder", other than that latter term is more widely used in the Windows community?
Often though it just reflects how recently you started using computers (more than MS vs Unix). I predominantly work in Windows but I call them directories but then I started with MS-DOS (and you type "dir" for a listing, right?).
If you started using computers with a GUI (and that's where you're most comfortable) then you might think of them as folders because on most platforms that's what the icon looks like.
I think the "folder" metaphor starts to break down a bit as soon as you're dealing with remote systems. Navigating to a parent "folder" on a remote FTP sounds weird to me, and it's telling that when browsing a FTP in a web browser even Internet Explorer 11 refers to directories - e.g. "Up to higher level directory" not higher level folder.
Everyone should, at some point, read The Unix-Haters Handbook. A great deal of it is outdated or simply wrong, but it does have a running theme of a prediction that has largely been borne out: people assuming that all Unix's flaws are actually virtues and that if you don't think so, then you Just Don't Get It. It's not hard to see how this happened: since pretty much all computers that people normally interact with a…
I love motorcycles too. I've owned many sophisticated bikes: Ducatis with their strange Desmodromic heads. With the ability to dial an exchange of torque to horsepower at the handlebars. Buells with their fuel-in-frame chassis. My current Suzuki even has 4 sensors in the airbox alone. One that measures the air input pressure. One that measures the oxygen level. One that measures the air temperature. Really amazing pe…
Although I agree that Unix is a big collection of hacks and well past its prime, the author displays several fundamental misconceptions of what he's talking about. Here's a few examples: - Dirty hacks in UNIX started to arise when UNIX was released, and it was long before Windows came to the scene, I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself). At leas…
Totally agree. The article doesn't show deep understanding of the actual problems. - make's TAB "problem" as very first argument is not very convincing. - The citations to back up the claim that a (possibly binary) registry database was better than small text files are just not backing up. There is nothing to defend a registry there. The quote is about fsync semantics which has nothing to do with registry. Btw. in my…
> We call touch in the loop here (I do know that the code can be re-written with xargs, so that touch is called only once; but let’s forget about it for now, okay?)...This means there is a new process for each file. This is extremely inefficient. Code in any other programming language will work faster than this one.
WHAT THE HELL??? Did he just criticize Unix/POSIX for its inefficiency after willfully choosing a less efficient way?
He wrote
find foo -print0 | while IFS="" read -rd "" A; do touch -- "$A"; done
find foo -print0 | xargs -0 touch --
Earlier quoted context omitted.
UNIX and C are symbiotic, regardless of whatever runs on top, only POSIX and C are common to any UNIX. Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.
>only POSIX and C are common to any UNIX. What about something like this: https://www.redox-os.org/ Its written in Rust not C. In fact, according to the github stats, there is no C. >Rust 72.4% >Shell 13.2% >Makefile 12.5% >TeX 1.9%
Earlier quoted context omitted.
It was an OpenVMS derivative wiyh code copied or clean-slated against a modified form of its behavior. However, I heard the networking stack was from BSD.
The IP stack is. There's even still an etc/ directory buried in the Windows tree to support it.
Earlier quoted context omitted.
UNIX and C are symbiotic, regardless of whatever runs on top, only POSIX and C are common to any UNIX. Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.
It was an OpenVMS derivative wiyh code copied or clean-slated against a modified form of its behavior. However, I heard the networking stack was from BSD.
Earlier quoted context omitted.
Inertia is only proof of inertia.
Suggesting that Unix has been continuing just by inertia doesn't explain why Apple adopted Unix for macOS or why most newer computers nowadays run a Unix OS.
Apple failed miserably to create a new OS, decided to buy a company instead and they happened to get the one where Steve Jobs was.
NextSTEP was partly based on UNIX, because it was competing against Solaris and needed some compatibility for easing the port of applications.
It used a micro-kernel like architecture, drivers where written in Objective-C, the whole userspace used the Foundation libraries and the bundles concept, the GUI was based on Postscript engine.
All very little to do with what a UNIX is.
Also if Gassé didn't ask the crazy amount of money he did, Mac OS X would probably be based on BeOS, which didn't have anything to do with UNIX.