261–270 of 318 posts
Earlier quoted context omitted.
The simple fact that the Registry doesn't have comments is ludicrous.
What database has? To clarify: The registry is a database for OS or application stuff (caches, settings, etc.). It's not meant to be user-editable and outside arcane trouble-shooting stuff you're unlikely to ever have to venture in there.
... is exactly the reason to have useful comments in there.
To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other ex…
> "Oh but isn't it neat you can pipe it to grep?" NO! No it's not neat, maybe it was neat 20 years ago. Today I want that damn data in a structure. Then you can still print it out in one line and pipe it to grep all you want. The systemd journal works how you describe, and it is very painful to interact with. I'll take plaintext logfiles any day of the week. It's fine if you want to interact with the log in ways that…
All the things that you mention can in theory be fixed over time.
The stuff I'm talking about is not for the next 6 months. It's not very meaningful to compare it against the current tools and landscape.
I can almost imagine a similar conversation in the past.
Someone saying "MAYBE ONE DAY WE CAN FLY!" and everyone's like "BUT OUR HORSES CAN ONLY JUMP 2 METERS HIGH! It would never work."
I understand your comment from a pragmatic point of view but none of those problems are big or important enough that we couldn't fix them in other ways.
Throwing away a rich structured piece of data and trading that for a dumb line of characters that needs to be re-parsed just so that it's easier to use logrotate and tac with them and so on is a losing trade.
Earlier quoted context omitted.
That project is a symptom of manual pages not having good “EXAMPLES” sections. The examples on that web page should be contributed upstream to the manuals pages of the software that they are for.
The issue isn't just the lack of EXAMPLES, but also with how man pages tend to be structured. They tend to be very "encyclopedic". There is a set ordering for sections, with a lot of them very verbose, and examples, when present, near the end. Options are often listed in alphabetic order, which doesn't usually correspond to how often they are used or useful. Man pages are OK when you're first learning how to use some…
The FreeBSD, TrueOS, and related worlds put the "using" doco into what are often called "handbooks" or "guides".
* NetBSD Guide: https://netbsd.org/docs/guide/en/
* FreeBSD Handbook: https://freebsd.org/doc/handbook/book.html
* DragonFlyBSD Handbook: https://www.dragonflybsd.org/docs/handbook/
* TrueOS User Guide: https://www.trueos.org/handbook/trueos.html
* PC-BSD User Guide: http://web.pcbsd.org/doc-archive/10.1.2/html/pcbsd.html (viewable off-line directly in both PDF and HTML forms in /usr/local/share/pcbsd/doc/)
Some parts of the Linux world do the same. upstart had the Upstart Cookbook for example:
* http://upstart.ubuntu.com/cookbook/
The Linux Documentation Project was supposed to contain a wealth of this stuff, but large parts of it are seemingly moribund, and incomplete after decades or woefully outdated. Wikibooks tried to take up the slack with an "anyone can edit" Guide to Unix and a Linux Guide:
* https://en.wikibooks.org/wiki/Guide_to_Unix
* https://en.wikibooks.org/wiki/Linux_Guide
If you want examples and doco that works from the basis of what you usually want to do, then these handbooks and guides are the places to go, not reference manuals.
Earlier quoted context omitted.
> It's often a stupid rule. By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.
But there is a limit to much respect you should pay to your elders. UNIX was invented over ten computer generations ago, and it's inventors couldn't possibly have imagined the world we live in today. And given that Windows is the dominant desktop OS, not Linux, the "decades of useful outcomes" favors my argument so I don't know who is the ignorant one.
... except that they could and did. People were not lacking in imagination. A science fiction writer imagined the Internet-connected smart 'phone in 1976, and put it into a science fiction novel (calling it the "mini-sec") titled Imperial Earth. A decade before that, an engineer imagined windows, hypertext, the mouse, word processing, graphics, and video conferencing, and gave what was later called The Mother of All Demos in an ACM/IEEE conference in 1968.
Earlier quoted context omitted.
> It's often a stupid rule. By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.
I think it's great that someone is questioning the way things have always been done, even it's just by calling it stupid. The hard part is coming up with something better. Unix at its core is still a product of the computing environment of the early 1970s. Not only that, it was a reaction to the complexity of Multics. What gave Unix an advantage at the time was how relatively easy it was to port to other architecture…
If you've taken the time to understand why generations of professional have done that way, and if you you have something else to propose, than the discussion is welcome and the result will be interesting in every case.
Otherwise, it's just a waste of time.
Earlier quoted context omitted.
Someone unfamiliar might just be dumped into vi because some other program thought it'd be great to open a text editor, e.g. for a commit message. You're unlikely to run vi intentionally unless you also know you want to run vi and how to exit, I guess.
I do think distros should change their default $EDITOR to nano.
It tends to annoy me, but it's easy enough to change :)
Earlier quoted context omitted.
In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…
Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many v…
There is one possible complication, though. The two would need to be reconciled in the same way by everyone who wants to write a shell tool. Given that even fairly simple standards (RSS, HTML, etc.) cause lots of failures to comply, what are the odds of near-universal compliance in a larger and more diverse ecosystem like shell utilities?
Earlier quoted context omitted.
you already have a tool to check whether processes exist... 'ps'. This is the essence of 'small, single purpose programs that work well with each other' rule.
Actually, sending the zero signal to a pid as in `kill -0 ` checks whether that pid exists and whether the calling process has permissions to send signals to it.
Interestingly, it would only take the addition of a pdopen() to something like FreeBSD's pdkill() to get enough for a tool that opened a process descriptor, sent a signal to the process, and determined (with poll() and pdwait4()) whether the process then exited; with the open-descriptor-style interface guaranteeing that it was always referencing the same process.
Earlier quoted context omitted.
I think it's great that someone is questioning the way things have always been done, even it's just by calling it stupid. The hard part is coming up with something better. Unix at its core is still a product of the computing environment of the early 1970s. Not only that, it was a reaction to the complexity of Multics. What gave Unix an advantage at the time was how relatively easy it was to port to other architecture…
Verbosity is wasteful and time-consuming in today's environment as well. Most people on HN are developers and not as fluent as system engineers in shells and UNIX tools. The need for minimalist, "silent" UIs comes with fluency. This is also true for network engineers and database administrators.
No, it comes from wanting to reuse the tool!
Would you like your browser to open plenty of pop-ups with messages like "Congratulations! The font XYZ was successfully loaded from C:\foo\bar" or "That's incredible! I looked for a JPEG on server www.qqq.com ... and it was there!"? No, you wouldn't. And I wouldn't like "mv" to babble every time it renames a file on the hard disk.
Earlier quoted context omitted.
Well, I'm advocating for structured text , not binary . Mostly because I haven't seen a future-proof binary format yet, and editing binary formats indeed would require special tooling. I think - for a data exchange protocol meant to be used between many applications - going structured text instead of binary is a worthwhile tradeoff of little lower efficiency vs. much better accessibility. EDIT: Some comments here are…
Let's say I want to know how many days since an asset on my web server has been modified. With bash + some standard unix tools, from the top of my head I have to do something like this: curl -svo /dev/null http://example.com/file 2>&1 | grep Last-Modified | cut -d ' ' -f 3- And that's just to get the last modified date in text form. Now I'm writing a script that parses that date and gets today's date, convert them to…
curl -j example.com|select headers.Last-Modified|time before now|time to days