lambda

> Since the most painful area is still the missing Cocoa implementation, hackers are welcome to explore the following possibility

I wonder why they suggest trying to rebuild Cocoa on top of Qt, rather than starting with the existing GNUstep?

The W3C HTML specs are pretty much irrelevant for anyone wanting to write a web browser, or author content designed to be consumed by web browsers.

There is pretty bleeding-edge support for compiling to both asm.js and WebAssembly in Rust that recently landed: https://users.rust-lang.org/t/compiling-to-the-web-with-rust...

So, at the very least there's support for C, C++, and Rust at the moment, though of course since the standards aren't yet finalized and the toolchains are evolving how well it works at any given moment may vary. I'm sure there's work going on for other languages to compile down to WASM, just not sure of the status of any other languages at the moment.

A DoS from a program already running on the same hardware is nowhere near the same level of vulnerability as a privilege escalation.

Security is all about increasing those difficulty thresholds, not absolutes.

For a very large number of people, these aren't "extremely niche use cases."

Something more comparable to Bitcoin than regular banking would be Western Union; they make 5 billion dollars a year in revenue transferring money. And they charge vastly higher rates than the Bitcoin network does, charging in the 5-10% range for for transactions, which is a pretty hefty overhead.

Command-period is the native Mac way to do it, though ESC works as well.

Command-period on macOS.

The processor speed is less important to me. But the lack of more than 16 GB of RAM is a serious problem. As a developer, I frequently run a large number of VMs at once. My current laptop has 16 GB of RAM, and I frequently need more to run all of the VMs that I need, so I wind up having to use my workstation with has 32 GB of RAM, and just connect to that remotely when I'm on my laptop. That's cumbersome and doesn't work well when I'm on the road in places with flaky connectivity (I travel a lot, as I work remotely and come into the office, so being able to do all of my work on my laptop would be a big win).

The escape key issue doesn't bother me as much, but I'm not a Vim user and I already have Caps Lock mapped to escape or control depending on whether it's a modifier or not. I do use the function keys occasionally in cross-platform development tools like gitk, but I'm sure that other keybindings can be substituted and I'd be able to deal with that.

But the lack of RAM beyond 16 GB pretty much means there's no reason for me to upgrade from my 3 year old laptop. I would have considered upgrading this cycle if they offered more RAM, but as it is I'll probably hold off. Maybe if they release another in a year or so with more RAM I'll upgrade; if not, I may just switch to a Lenovo or other laptop that has more expansion room.

3 years without a bump in RAM capacity seems like an awful lot. I realize that Moore's Law is flattening out, but stagnating for 3 years like this seems like a long time.

I'm an Emacs user though, so I like it being Control as a modifier/Escape if pressed alone. Just having Caps Lock function as escape wouldn't help.

Ah, that's disappointing. Another reason to be glad I haven't upgraded yet, I guess.

Also, wow, I'm glad I don't maintain any popular open source projects on GitHub: https://github.com/tekezo/Karabiner/issues/660. I can't believe the number of people who think "+1", "me too", and "donated" messages are at all helpful.

Also, looks like Karabiner Elements exists as a rewrite for Sierra. https://github.com/tekezo/Karabiner-Elements Haven't yet checked if it supports the same dual behavior, though.

On my laptop, I already use Karabiner to make Caps Lock function as Control if used as a modifier key, and ESC if just tapped. Much easier to reach, works for both Emacs and Vim keybindings, only issue is that sometimes you hit ESC by accident if you start doing a chord but then decide against it. I personally think this is a better solution than a soft key for escape, but it may not be to everyone's taste.

This seems needlessly negative; and you seem to be inferring a lot about what Linus wants without him having said anything. The one thing he's asked about so far on this patch series is how it handles resource exhaustion/denial-of-service issues, and they have a reasonable reply, though there may need to be some iteration there: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg...

The last attempt, kdbus, was definitely way too complicated and funky. It went through a few rounds of review and was never merged for a good reason.

This redesign from the ground up does a lot of what you are asking for. It derives inspiration from other, well respected, capability based systems, as well as other IPC systems for the Linux kernel, like binder, which is used on one of the most popular Linux based consumer platforms, Android.

Linux already supports the IPC mechanisms supported by most of the BSDs; pipes, Unix domain sockets, POSIX IPC. But these actually have a number of shortcomings for building reliable, efficient IPC between processes.

Another inspiration that they cited as inspiration in the announcement of their talk (https://www.linuxplumbersconf.org/2016/ocw/proposals/3819), used by the most popular consumer-oriented BSD, is Mach message ports, used on in XNU, the macOS/iOS kernel. However, those are not an ideal API to adopt wholesale, as shown by the serious vulnerabilities based on trying to integrate them with a monolithic kernel: https://googleprojectzero.blogspot.com/2016/10/taskt-conside...

I would say that they have done most of what you ask. They have investigated the existing solutions, and found them wanting. They have already gone through one design that they threw away due to it being too complicated. They have picked a model that is widely respected and implemented in one form or another on most systems, a capability based model. There's a little bit of new invention here due to the ability to multicast messages and their message ordering guarantees, and probably some room for iterating, but overall, this looks like a pretty promising IPC system compared to the fairly overwrought kdbus.

And yeah, an ioctl interface may not be the prettiest, but they've said that they're using that over syscalls just because it's easier to implement and iterate out of tree that way before getting it merged, but are willing to switch to a sycall based interface if that's preferred: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg...

Besides the ioctl vs. syscall issue, which is pretty much just an implementation detail that can be solved with a wrapper API or done away with before merging, what do you find not in good taste about this proposal?

Twitter's working fine for me. This attack is affecting different people differently; as a DDOS, attacking a distributed system (DNS) with a lot of redundancy, it's possible for some people to be affected badly while others not affected at all.

I briefly lost access to GitHub, but Twitter has been working fine every time I've checked. Posting status messages in multiple venues helps to ensure that even if one channel is down, people might be able to get status from another channel.

Very few people can read and understand C without being a language lawyer an knowing tons of esoteric magic. There are many things in C which look perfectly reasonable but which actually result in undefined behavior, and you cannot reason about what a program will do in the presence of undefined behavior.

The existing patent agreements are a contributor agreement, not part of the license. So, they restrict people from contributing, but don't actually provide any guaranteed protection for downstream users, as far as I can tell.

However, I'm not a lawyer and not involved, was just trying to summarize as well as I could, so I could be wrong.

Every one of the cases I have had to debug in which someone had deleted the localhost entry was someone who had entries for blocking Adobe's licensing servers.

LLVM wants to switch from a BSD-style license to Apache 2.0, with a few exceptions, one allowing use with GPLv2 code, another allowing the bits of compiler-rt and other components that get built into binaries to be redistributed without restriction.

The main benefit of Apache 2.0 is that it includes a patent grant as well. Right now, LLVM relies on a custom "developer agreement" for anyone who contributes code that includes a grant of patent rights, but it's kind of vague and fuzzy and so makes it hard for some people to contribute, and the license itself doesn't actually mention patents at all:

http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...

Theo objects to any license that applies more restrictions than the original BSD license. OpenBSD makes an exception for GPLv2 licensed utilities that have been traditionally shipped with BSDs that there's not a good replacement for, but has stopped upgrading things that have moved to GPLv3 and apparently objects to the Apache license as well.

The staging area is a lot more useful than what you can do with an interactive commit, since it persists between operations. You can use it to accumulate changes that are "done" while you continue to experiment with some other changes on top, even if you're planning on committing the whole thing at once, and if you wind up not liking your new changes, revert to what you had in the staging area; or you can realize what you're working on will be easier to finish as two commits, stage part of it, stash the other part, finish the part that was staged and commit it, then apply the stashed part and finish that too.

This is a lot more than you get with just a single interactive commit operation.

You could use a commit for this purpose, and continually amend or revert this commit, but in terms of UI, it's helpful to have a set of operations specifically for moving things in and out of the staging area that's different than what you do for manipulating commits on general.

I have had a number of customers who have broken our applications, which have daemons listening on localhost, by editing their /etc/hosts files and removing the localhost entry. I guess various people edit /etc/hosts to prevent applications from talking to licensing servers, and in the process happen to accidentally blow away the localhost entry (since these customers don't know what they're doing). We had this happen enough that we eventually stopped using "localhost" and started using 127.0.0.1 in our code.

No, absolutely not. If people choose that for a local domain, that breaks mDNS.

Several of the Uber/Lyft drivers I've talked to are actually former small business owners; they owned bakeries and pizza shops, and are now retiring from that by driving for Uber or Lyft, which over much better and more flexible hours than having to work 12 to 16 hour days that they do running their former businesses.

Others are people with seasonal or part time work; they work in real estate or as relationship therapists, but use driving for Uber and Lyft to cover for the times when they're less busy.

Some more are people who are just bored during the day, and want to give people rides.

A few are college students, trying to make ends meet as they pay their way through school.

And a few more are doing this full time; some are former cabbies, who find they get a lot more business this way, some are people who never would have been cabbies, but are able to find some income from Uber or Lyft.

Why would programs want to "depend on the invariant that the size of a cache line will stay constant"? That's a minor detail that most applications don't care about.

In this case, it probably mattered because when JITing code, you need to explicitly flush instruction cache after changing code. But that's not anything the application cares about; that's something the runtime cares about, and the runtime is going to want to support taking advantage of the speed/power tradeoff without making application developers have to go to the trouble of thinking about it.

Also, from a user perspective, you don't want applications to be able to demand only the big, powerful cores. That will eat through your battery much faster, with likely very little benefit.

But then you would never be able to take advantage of the power/performance tradeoff that big.LITTLE gives you; of being able to migrate you to a big core when you need it, but save power by migrating you to the little core when you're not doing anything CPU intensive, and shutting off the power-hungry big core.

Right now, I have a MBP retina with 512 GB of SSD, 16 GB of RAM.

I could upgrade to one with the ability to drive a 4K monitor and 1TB SSD, but that's pretty much the only noticeable improvement. Sure, the CPU and GPU will probably be somewhat more powerful, but RAM and SSD space are actually my limiting factor most of the time right now. In my development, I need to run a lot of VMs, so RAM and SSD capacity are things I really need as much of as possible.

So, offering something with 32 GB of RAM, and probably a larger SSD, would make it more worthwhile for me to upgrade.

So, I think you are over-generalizing from a particular piece of anecdotal evidence.

You, yourself, have spent a lot of time online and been exposed to a lot of nasty behavior, and you don't find that a lot of rude comments bother you.

From this, you conclude that those years "desensitized" you.

Other equally valid hypotheses are that you were less sensitive to such comments in the first place; the reason you hung around, and kept on interacting in the kind of places that make such rude comments, while other people may have just spent time with their meatspace friends, is that you were less sensitive than some other people who saw nasty comments, got bothered by them, and stopped hanging out in such forums.

Or another ones is that those comments you say you are desensitized to are just things that you don't care about that much. OK, so some anon was rude to you about a throwaway comment on an imageboard. Big deal. But you might react differently when people in a community you trust or which might be influential, and which you want to value your work, actually say negative things about something that you have put a lot of your life into, but have had doubts about whether it's really the right thing for you to be doing.

The list goes on. There are a lot of possible conclusions that can be drawn from "spent a lot of time on the internet and exposed to online abuse in youth, now finds self not particularly sensitive to online rudeness." Taking from that that some people might take offense at things because they haven't had such experiences is a big leap.

If it's a gateway to a paid service (music stores, Uber, Lyft, etc), it generally won't have ads.

If it's free, but not a gateway to a paid service, I check to see if source is available; if source is available, it generally doesn't have ads (and if it does, I can just build it myself and remove them).

If the above checks fail, I check for a paid, ad-free version. If such a version exists, that implies the free version has ads. If the price is reasonable, I'll buy it, otherwise I'll skip it.

Finally you have free-as-in-beer but not as in freedom apps, that don't have paid alternative or any other way of generating revenue. I just assume those apps are either encrusted in ads or scams, so I don't install them.

Huh. I've just never installed any ad-based applications. If there's a no-ad paid version for a buck or two I'll buy it, otherwise, I just don't use it.

This is great! I was actually looking recently to see if there was any definitive guide to best practices in single and multifactor authentication, and this is a pretty good description. Would be nice if there were a separate guide on actual implementation of such systems.

I really appreciate this section, as I have been frustrated in the past by stupid password complexity requirements that actually reduce the amount of available entropy for passwords: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

Note that this might have been a better link, giving an overview of the whole series and development process: https://pages.nist.gov/800-63-3/

Hmm. I wonder why one of the followup mitigations is not to move to a non-backtracking regex engine by default.

Most of what you want to do with a regex can be done with an NFA or DFA based engine. That which can't be done with an NFA or DFA based engine is generally better handled with a parser than a regex.

There are plenty of good DFA based regex matchers out there; RE2, the Rust regex crate, GNU grep, etc. At a glance, it even looks like glibc uses a DFA, though it supports POSIX REs which support backreferences so it must use backtracking at least for REs that contain backreferences.

Predictable hash collisions were a big sources of DOS attacks in web scripting languages which use tables a lot, until they started rolling out randomized hashing algorithms to prevent easily predictable hash collisions. It seems like it would be best for languages and libraries to move to DFA based regexps, at least for anything that doesn't contain backreferences, to mitigate these kinds of issues from being easy to exploit.

There's a fundamental difference. Radio broadcasts are generally considered public performances, and generally handled under blanket licenses with ASCAP, BMI, and the like. There is also a separate blanket licensing scheme for digital streaming radio, SoundExchange. There is no blanket licensing for digital downloads; thus, to provide digital downloads that contain music, PRI would have to negotiate separate contracts with each of the copyright holders.