fridsun

I just must let this one thing out.

> 34:02 binary logs are not a bad thing as long > 34:06 as you have the tools to pull them apart

Really? Did he just "as long as" the biggest downside of binary log compared to text log, that is way fewer tools work on a binary log due to its special encoding?

With the same logic, flu viruses are not a bad thing as long as you are immune to them.

What do you mean by "nothing impressive"? DeepMind's AlphaStar has beaten the world's best Protoss player 5-1 in Protoss vs. Protoss.

https://deepmind.com/blog/alphastar-mastering-real-time-stra...

Seems you'd also be interested in this article:

An Ivy League professor who spent 4 months working in a South Bronx check-cashing store says we're getting it all wrong http://www.businessinsider.com/check-cashing-stores-good-dea...

An interesting read I met the other day on check-cashing: http://www.businessinsider.com/check-cashing-stores-good-dea...

What's a fact if not an opinion so firmly believed that one has to suffer a cognitive dissonance when it's countered?

If you break those PC models open what's really different? The hardware interfaces of PC has almost always been stable since the age of IBM PC clones. It might not be a monoculture in terms of all the RGB lightings you can put on your machine, but you definitely don't need to worry about different protocols. All the while Android phones can have the weirdest SoC's on the planet in them.

All nouns are labels. Labeling in an argument goes all the ways and there is no guarantee whatsoever the parties involved have the same recognition of the labels. That we even have enough common understanding to create a language is due to a special human ability to understand each other without precise language, thus labels. The problem is not using labels, but people who intentionally mess with said ability to understand and then plant the blame on labels.

> The goal would have to be silencing the social media presence of the right

*the alt-right

Or, less euphemistically, the neo-Nazi.

For all who question "why not just copy history to new tab?": it is part of the trail design. By saying they are not throwing the tab away they have most probably already done that. This will be another screen to view the trail, like the tab exposé on mac safari.

Rust is standardized with lots of docs. The rest two will come with time.

I've long thought that Haskell is much more intuitive than any engineering languages out there for people with no programming experience, since it builds on mathematics that everyone has already learned. It's great to see functional programming placed at the center of intro-level programming teaching.

The syntax looks really Haskell to me, so it's not that awkward.

OCaml or Haskell.

Lennart Poettering has replied on Reddit.

https://www.reddit.com/r/linux/comments/54yfcd/how_to_crash_...

> So let's summarize this. There's a bug in some software. OMG! Shock! This of course never happened before!

> The bug is in not exploitable remotely. The bug does not allow privilege escalation nor insertion of code. This of course makes the bug a massive vulnerability like there was no other on the planet ... ever. As bad as heartbleed multiplied by the Debian OpenSSL random generator bug to the power of 10.

> The bug is caused by an error check that filters out garbage sent to PID 1. The check works correctly, except that the resulting action is a too harsh: instead of complaining and dropping it will abort the process. Such a bug is of course unprecedented and the authors of said software should be stoned and flogged right away given the severity of the issue: after all a safety check worked a bit too well, and we really can't have that because undefined behaviour of course would be a lot better than a local DoS.

> The project the error was found in is large. Yet the number of CVEs collect so far is pretty small comparing it witht other projects of similar extent. Given that another bug was discovered now this obviously shows how incompetent the programmers are and that security is a unknown concept to them.

> The program the bug was found in is longer than 50 lines of code but runs with privileges, all written in a low-level programming langauge that many call little more than a fancy macro assembler. The code runs on top of an operating system kernel written in the same language but running with a lot higher privileges and consisting of expoentially more lines of code including drivers of questionnable quality. This together is of course proof that the project at hand is flawed conceptually to its core.

> Dha!

> Lennart

> (More seriously: yes this is a bug, we should fix it. But it's very low impact and the bruhaha it generated appears wildly out of scale. If all bugs in the wider Open Source ecosystem would have a similarly low impact we'd live in a much much safer world!)

It was quite amusing seeing systemd causing systemd-specific trouble in CoreOS development though, such as systemd requiring too much privilege when running inside container. Many people just use s6 happily.

Clearly you have missed this article: http://blog.darknedgy.net/technology/2015/09/05/0/

You just described how daemontools family works. They are less monolithic than systemd because they didn't subsume udev.

Now that Apple ditched the headphone jack in iPhone 7...

Windows definitely can do that.

Why would IBM care? It's AIX is live and well.

Canonical tried to compete with Upstart but failed.

What's curious is why Debian fell. It was the cornerstone.

I always thought sexual assault IS rape. How are they different?

A bit surprised to see a Chinese project on coding.net on HN. Applause!

That said I am constantly stuck in a state where I cannot backspace to delete what I wrote.

Not open source, but 1Password has been my choice for the past two years. Usable on Linux via Wine, storage delegated to 3rd-party and great iOS app keep me in.

In the end it's possible in any language to produce exploitable bug (apart from maybe Erlang VM?). The point is about 1) how hard (probable) it is, 2) how popular are error checking tools (C static analyzers, Google Thread Sanitizer, etc), and 3) how fast can the culprit code be found and fixed.

In that regard Rust has reduced both 1) and 3) by only exposing dangerous features in unsafe {}, and greatly improved 2) since the compiler itself is checking those errors.

In the place of litigation fees you pay software development fees. Not that I am really against it as a developer.

Smart contracts are different from self-driving cars in that the former have competing intents within while the latter have a common goal of "not hitting anything".

Do your prior work investigation and try to take the good and avoid the bad.

Some prior work from top of my head:

- Bountysource - Gratipay - Patreon - Flattr

People against it are extremely vocal because it is much harder to work around than previous stuff. Don't like PulseAudio? Use alsa directly is fine, I did in my Arch Linux box. Don't like Flash? HTML5 FTW. Don't like systemd? I have to go to FreeBSD altogether.

I am using PC-BSD and the network is configured with a GUI and working fine. I don't know what's about network-manager.

The problem is there are better things before systemd, namely daemontools (and its derivs runit, s6, ...). It wasn't popular, presumably because people didn't care that much.

OTOH, Nosh offers a tool to auto-convert service files into equivalent daemontools shell scripts: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Few seems to care enough either.

History of modern init FYI: http://blog.darknedgy.net/technology/2015/09/05/0/

My 2 cents: init script wasn't a enough pain in the ass for people in charge to search for alternatives but still a pain, and systemd was introduced to them by Red Hat manpower. It seems good enough so they went with it.

Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.