74 karma · joined July 18, 2013
Not sure what I missed. It must have some other redeeming qualities besides this one. :)
Learning to master nc and tcpclient before curl* had the same effect. I guess I am missing all the fun.
*There are so many features, so much rarely used code, I'm not sure one could ever hope to fully understand all the implications.
I took this angle early on and have never had second thoughts. As they say, "It just works."
Glad you are seeing the benefits.
However, I think "WiFi" is a strong marketing signal. Even if it does not work as well as Ethernet at transferring data, it appears to work well to sell products and services.
"I really don't know how this tech is going to work..."
It may not have to work. Consumers of computing devices have developed a high tolerance for stuff that is either ridiculously slow or does not work. Many do not know any different: when none of the devices people use have an Ethernet port, they will never know the speeds they are missing. The choice of using Ethernet has been removed.
I use my own cache, not shared with anyone. Do I really need to worry about snooping?
I also use CurveDNS with the authoritative server that serves my version of the root.zone.
Practicing my CurveDNS skills for that day when more authoritative servers are using curvedns. Not sure that day will ever come.
I interpreted this to mean encrypting each DNS packet.
Maybe I misread the statement?
DNSSEC of course does not protect the contents of the packet.
Instead, DNSSEC more or less is just another CA system (or an adjunct to the existing one), running over UDP.
About the price of a domainname? (Note I did not use the word "cost". I create dommainnames all the time at the price of $0.)
Given the choice between a domainname and an IPv4 adddress, I would take the IPv4 address.
Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address.
IPv4 is "simplicity" in comparison to the complexity of IPv6. IPv6 has features I do not need.
Whenever I am granted the choice, I always choose simplicity over complexity.
Most of the time the additonal complexity is not needed and can only cause problems in the long run.
This is only the opinion of one "consumer". Certainly the "market" may have another opinion.
Microsoft? Amazon?
Does it make a difference?
If my company starts selling cloud hosting and then I announce my company will be hosting its internal applications in "the cloud" (i.e., in my own data centers), what are the security implications for my company?
Are they the same if some other company asks me to host their applications in my data centers?
Is this article a PR piece (or "submarine" as PG calls it)?
What do you think?
"Oracle or Microsoft"
Would any self-respecting programmer follow along with such idiocy if they were not paid to do so?
I humbly request some illustrative examples. Note I agree with you. Examples can be powerful (and, unfortunately, polarizing). Whatever you can share would be appreciated.
Perhaps he is not suggesting that popular ideas likely to be are wrong.
Instead maybe he is saying that to think and develop ideas like Knuth's one needs a certain amount of irreverance for what is popular.
(Undue?) reverance is rampant in the software industry, in my opinion. Would Knuth agree?
It is possible he was very good at deluding himself.
Perhaps that self-delusion is contagious.
If one wants to believe something strongly enough, then maybe one can believe it.
If people want to believe that the only way to produce great form factor and ease of use in a computer is to be Jobs-like and conduct "business" like Apple, then they might believe that, even if there is a good chance or evidence this behaviour is not necessary.
It seems people have a difficult time separating the Apple products from the organization that sells them.
One may be worthy of adoration, the other may not.
Solution:
1 Entrepreneurs petition VC firms to all post a CSV file (Excel file saved as .csv) listing what they have invested in, dates, etc. Is there a single VC firm that does not have this data? Most likely the data has at some time been put into a spreadsheet or some form of report.
2 VC firms locate the spreadsheet, delete any confidential columns (Alt+Space, Alt+H,D,C), save as Comma Separated Values (.csv) and give the file to their web developers.
3 Web developers upload the file to web servers.
4 Entrepreneurs download CSV file.
It seems that some Linux users are unhappy with systemd.
While I do not agree with any user being disrespectful to the author by targeting him personally, the fact that users are seriously upset about systemd as a program gives me hope for the future of the popular Linux distributions.
When the author says "Open Source is awful" maybe he is revealing his true colors. Perhaps he is better suited to closed source development which is insulated from public review by users and other developers at-large. But that is for him to decide.
There was a post on HN a little while back by the developer of a popular glibc alernative for Linux who told us he has been using a flat, linear /etc/rc file for over a decade and his boot times are substantially shorter than with systemd. But more importantly, his approach is simple by comparison. How many users will be able to debug systemd by examining the internals?
It is this type of "hands-on" user that gives me hope for the future of the distributions that are experimenting with systemd. I hope these users will speak up if they have not done so already.
I have had to remove the IPv6 option from my kernels because enabling IPv6 by default (which to me seems like a "policy" decision) has become so pervasive. Nice to see this change; here's hoping other OS's follow suit.
The title of this one started off as "free" SSL. Now it is "universal SSL". C'mon. As vader1 points out, the level of potential deception here is getting a wee bit high.
CF is just a MITM. A website owner lets CF control her DNS and this allows CF to route all requests for her website through CF servers; CF stands between the website and the user.
Unless the website owner configures SSL then the user only gets an encrypted connection to CF. That's hardly "universal" SSL.
Truth is I'd rather read someone else's shell script than someone else's C, python, ruby, javascript or other code. Not to say it still isn't painful reading; most scripts I see are nonsensically verbose. But it is a much less time-consuming read.
Unless, of course, it is written in a shell like Bash, i.e., one with too many extra features to keep track of. Like, say, exporting of functions, for example.
Anyway, djb uses shell scripts liberally in his software projects but I've never seen him include a shell script with Bash-isms. That tells me he does not _assume_ his users to be using Bash.
Everyone has a choice. And if you are trying to practice "secure" computing, then some choices are wiser than others.
If a user thinks Bash is the bee's knees, then djb's software will work just fine; it does not discriminate against that user.
But if a user does not use Bash, and prefers to use a more simple, POSIX-like shell, that will work just fine too.
This is purely my opinion but unlike so many other software authors, djb does not appear to discriminate against people who prefer simple software systems that are not loaded with "features"; he does not intentionally or unintentionally force them to embrace complexity or be ignored.
That said, it also appears he is a self-professed Ubuntu user these days. For example, read his latest blog.cr.yp.to entry.
I do not understand how he can tolerate the amount of complexity in Ubuntu that is on by default and hidden from the user. But maybe I'm just too stupid to understand.
There seems to be a choice of at least two options:
1. keep Bash installed and try to determine every possible untrusted user input accepting or internet facing application that might at some time use the system shell, or
2. uninstall Bash and use a barebones POSIX-like shell without extra features.
Preserving the continued use of shell scripts with Bash-isms as a reason to choose option #1 does not make sense to me. Maybe there are other "compelling" reasons? (Interactive shell features?) With a little effort, these Bash script authors could probably learn to write scripts that do not use Bash-isms. Is that really so terrible as to make option #2 untenable?
If there are enormous Bash scripts being relied on in security senstive settings which "cannot" be rewritten in POSIX shell, then maybe the mistake was ever "deploying" such monstrosities in the first place.
Shell scripts, no matter what shell, should always be relatively small assuming the author has any common sense.
All the ones I know only want to sell "features".
Your words are absolutely 100% true, 1wd.
But I have become cynical that the world of software developers and their best customers (e.g., the ones who love "features") will never, ever follow your advice.
Personally, I prefer minimalism irrespective of the security benefits. But "engineering", a term many HN readers might attribute to their own work, like to speak of "trade-offs". All engineering involves trade-offs.
When you go without "features", sometimes you actually get something in return. What you "get" might not always be obvious. This week, it should be obvious. At least to everyone who chooses a more minimal shell without surplus features.
http://mywiki.wooledge.org/Bashism http://news.ycombinator.com/item?id=6866696p
I write hundreds of shell scripts per year and I never, ever use bash. Everything can be done with a less complex /bin/sh having only POSIX-like features.
There's no reason webservers have to use bash by default.
Sysadmins might need a hefty shell will lots of features in order to do their work, but an httpd should not need access to bash-isms. It should work fine with a very minimal POSIX-like shell.
I'm glad the systems I use do not have bash installed by default. The only time I ever use it is when a software author tries to force me to use bash by writing their install scripts in it and using bash-isms so the script will not run with a simpler shell like a BSD /bin/sh.
I already did this many years ago. It works well.
I also do not use DNSSEC (unencrypted DNS packets) opting instead for dnscurve (encrypted DNS packets).
What is still missing from the DNS world is a server that can handle pipelined (TCP) DNS queries (multiple lookups in the same request). I think the spec allows for it but no one ever implemented it as far as I know.
In your thought experiment, that would be "HTTP/1.1 pipelining".
I use HTTP pipelining everyday via command line utlities and where "web browsing" is concerned I find it hard to live without.
You can substitute other tcp clients for curl.
And the openssl binary is ubiquitous, so he is smart to use it for generating base64 versus other userland utilities for generating base64 that are not always found outside of GNU/Linux.
I no longer have a Blackboard account, but if I did, or had a guest account to play with, I would try rewriting your Bash script in POSIX-like sh.
Nice work and a good choice of project.
The current system I use takes about 220MB of RAM and about 15min on an underpowered netbook. (It is not Linux but still has decent hardware support.)
Of course I'm also curious what other folks who compile their own Linux kernels see as their "minimum" requirements.
This is easy for me to do because I run my own DNS root.
I also use DNS in order to log requests from devices that phone home (e.g., Apple).
Strangley, these often feel more "powerful" to me than the structured languages I use. Especially when writing small programs.
When you were experiencing long wait times, did you turn off line numbering?
less -n logfile