With printf, you do have to look at the docs to see what the string conversion function is. With iostream, you still have to look at the docs to see if the ostream operator is implemented for the class, it's certainly not universal.
It's a pain to format text. Things like: printing an int in hex, printing a zero-padded int of a specific length, printing a float to two decimal places. And having those formatting changes be stored silently as global state leads to unexpected behavior.
So is this a real thing? I've never seen this pigdog website before, it's second newest article was published in 2012, and there's no mention of this on the perl 6 home page or in the perl 6 announcements mailing list..
You know, the funny thing is I never exactly considered myself a systemd supporter. I just get tired of the comments from people bashing systemd which are almost always emotional and political rather than technical in nature. Maybe there's good technical arguments for some other system but they get drowned out by the "systemd is a nightmare with zero benefit that was written to make linux a desktop OS" comments..
It's hard to argue with someone who claims that systemd has zero benefit.
You claim unit files are confusing. Let's say we took a Windows programmer who was a sophomore in CS but didn't have any Unix or Linux experience, show him both systems. Explain how runlevels are handled in systemd vs sysvinit. Show him a systemd unit file vs the equivalent bash script. Explain how systemd tracks the process tree vs sysvinit pid file hack. You spent five minutes trying to figure out systemctl and declared it terrible. It probably took you more than 5 minutes to find /etc/init.d your first time
It's because every argument I've seen against systemd is by people who think systemd betrays the Unix philosophy and think we should go back to sysvinit (see rconti above). Upstart had a lot of problems, and the only good technical arguments I've seen in its favor are better compatibility with other kernels. Please point me to a good "Upstart is better than systemd" technical article.
The linux kernel is breaking the way Docker currently uses cgroups. And systemd is providing a fix for systems running systemd, but this is their fault because systemd is not also providing a fix for systems that aren't running systemd?
If you don't like systemd in general that's one thing, but to claim that systemd only benefits desktops is just wrong. I'm just tired of the "systemd only goal is boot speed" argument. Too many people want to join the crowd and get their old-school linux user credentials by bashing systemd without understanding or acknowledging the benefits.
sysvinit maintainers must love systemd. Before systemd came along there were lots of complaints about what a terrible hack sysvinit is. Now it's a paragon of simplicity and stability without having actually changed any..
Presumably Docker offers some benefit. It's weird that you and several others have jumped to the conclusion that it's obvious they should get rid of Docker. I would say: knowing this information, why do you still think java is a good fit for their use-case?
I knew that no matter what languages I picked for my examples, that someone on hn was going to respond that yes, in fact language B is much simpler than language A. I believe you understood the comparison I was trying to make and I'm not interested in a discussion about how simple erlang really is, it's besides the point..
So, going by the number of books and tutorials metric, java is a much more complicated programming language than erlang? Have you seen how many books and tutorials java needs?
I think most soylent drinkers don't do it 100%. I drink it for breakfast and lunch, and do dinner with the family. So for me I do four servings over two days. I think they're finding that this a common pattern and updating the packaging to reflect it.
If you don't know what the problem was why are you so convinced it was systemd? Could be the kernel, could be udev, dbus, filesystem, or hardware (sorry, there is never 100% "known good" hardware).
But then it would have to either keep the passphrase in memory (just as bad) or ask for the passphrase each time you reconnect later (defeats the purpose of ssh-agent).
Edit: Nevermind, you're talking about ssh, not ssh-agent..
So quit your job at MouseTrap Enterprises before you go off and build your better mouse trap. If you have a job as a MouseTrap inventor at MouseTrap Enterprises and you have a great idea for a mouse trap, it does seem kind of sketchy to go off and create your better mouse trap at home on the weekends while you're cashing your MTE checks. That is what they're paying you for..
They do now, and the first one is still using strlen(). Does the existence of the second function mean it's now ok for the first to use strlen()? You can still crash the program if you send binary data to the string function instead of the binary function..
functions don't conform to specs, the API and library as a whole should conform to the spec. It's perfectly valid to have one function that supports strings and another function that supports binary data.
It is a logical leap to assume that because the spec says other types of data are valid that means you should be able to pass arbitrary data to this function that is documented as requiring a 0 terminated string. Let's say you wanted to pass an IPv4 address. Would you expect to pass it a uint32_t pointer? A struct in_addr pointer? Host or network byte order?
Yes, the spec says the field can be string or binary. The API only handles string fields. The API should be (and was) updated with a function that handles binary fields, but there's nothing wrong with the original function.
If this was C++, and the function took a std::string, would you say it was horribly broken because you serialized a 4 byte IP address into a 4 byte std::string buffer and the function didn't handle it correctly?
There's only so much an API can do with garbage input. If this function took a pointer and a length, that's not a magic fix, you could still pass it a bad pointer and/or a bad length..