uxcn

awk, sed, cut, etc... are excellent as long as the format is regular and you only need to process the file once

This may seem like an odd question, but strategically, why acquire the stake (aside from dividends)?

As I understand, ASML already depends on Carl Zeiss. I would guess ASML will depend more heavily on them with EUVL over the next decade, but I honestly haven't done the research.

Is this going to give them more control over production? Does it somehow reduce their costs?

People and businesses in countries like Venezuela, where the native currency is volatile and under strict government control, use cryptocurrencies. They're more stable (not as stable as USD/EUR though) and easier to transact (particularly cross-currency).

Okay... I agree adding features to email and IRC are probably not the easiest things in the world. There are a number of useful features that have been added to email over time though, and I don't think decentralized control of the protocol is the bottleneck. Wave might or might not be a good example.

I'm a huge fan of the IRC protocol, and I think I've set up IRC channels at nearly every company I've worked for.

Freenode and Weechat seem to support the changes, but I honestly worry that the protocol ends up more complicated than it needs to be, or possibly more complicated than people can use. Diaspora already provides a lot of what IRCv3 looks like it's trying to do. I guess I'm just not sure what the difference is.

Seattle has set up more than one tiny house village [1], at least that I know of. Some of them even have internet access.

We still have a very real homeless problem though, and you'll see panhandlers if you drive through the city. People have even set up camps along I-5.

[1] http://www.kiro7.com/news/seattles-first-tiny-house-village-...

It's estimated there are 10^80 atoms [1] in the visible universe, so 2^256 is definitely a huge number. I didn't realize 256 bit brute force was nigh feasible with only a solar system.

I'm a bit surprised the quantum algorithm only gives a polynomial speedup.

[1] https://en.wikipedia.org/wiki/Observable_universe#Matter_con...

ORWL was designed specifically to prevent undetected tampering with any of its electrical components, including the entire motherboard and storage drive. When tampering is detected, ORWL immediately and irrevocably erases all your data, even if it is unplugged at the time.

and...

Upon any tampering, the secure microcontroller instantly erases the encryption key, causing all data on the SSD to be irrevocably lost.

If only the key is deleted, wouldn't that leave the drive susceptible to brute force?

I personally think life is probably common in the universe. We've only been able to prove exoplanets exist within the last few decades, but the evidence is already that there are a number of planets that are hospitable to life (our kind at least). We've only just started scratching the surface and we've already found things like Tabby's Star [1].

Obviously I think there's a point to us trying to communicate with whatever is out there, I just think we shouldn't be surprised by the lack of response.

[1] https://en.wikipedia.org/wiki/KIC_8462852

This is a really good point. There has been a lot of research into this area lately, as well as animal intelligence in general.

My point is still that life less intelligent than us has nothing to communicate to us that we would care to respond to.

Two civs probably need to be within half a millennium or so of technological development (human time) to have any possibility of communicating.

Intelligence seems to expand polynomially or exponentially by a lot of measures though (e.g. technology). The closest analogy for us compared to another civilization that could actually receive our radio communication I think would be chimpanzees using sticks to eat termites.

If I had to guess, I'd guess there's probably some kind of technological asymptote, but considering the scale of the universe (more importantly its complexity) I think we are probably nowhere near it.

Yeah, I'd care about that octopus. I would want to study it and see what else it does.

Sure, I mean intelligent life is interesting to us because it's novel. If there is other intelligent life in the galaxy (universe), it probably implies that intelligent life is relatively common. So, more (less) intelligent life would be extremely inconsequential to them. Why waste resources studying something already well understood?

I think it's likely intelligent life outside our planet just doesn't, or won't, have any interest in us outside the infinitesimal possibility of a threat.

Consider everything less intelligent than us on our planet... If anything tried to communicate with us, would we even bother trying to figure out what it was trying to say? Would we try to communicate back?

Suppose an octopus stacked rocks in piles of prime numbers (not including unity). Would we care beyond possibly putting it on display in an aquarium?

jvisualvm is largely a superset of jconsole, with a plugin interface, so it probably is.

I have no idea how many other people actually use it though.

If it's exposed through JMX, would it also be visible via something like jvisualvm?

Autonomous software is a lot more complex than the software the ECU uses (which is still complex), so there may be a genuine argument against allowing people to modify cars not designed for autonomous driving. It definitely raises a really serious liability question.

Even with those systems working exactly as designed, there are some serious liability questions I don't think anyone has really answered yet.

Autonomous driving isn't really regulated though. Google's Chauffeur is the only autonomous software I'm aware has even passed a state driving test.

    “It is fully functional. It’s about on par with Tesla
    Autopilot,” Hotz said. It doesn’t have a lot of sensors
    as the Comma One relies on built-in car front radars and
    comes with a camera.

I would be genuinely curious what the development methodologies for Chauffeur look like, if anyone can point me in the right direction.

Another minor thing I think belongs in the C standard is bswap. For such a common operation that's necessary for portable code, I personally don't understand why it hasn't been defined in either the C or C++ standard.

Currently, the only compiler I'm aware of that optimizes a bswap correctly is LLVM, which leaves a lot of code in the cold Aside from requiring people to write their own bswap, which is fairly maligned [1] for good reason, It leaves out a reasonably important optimization or potentially requires excess maintenance (platform libs, intrinsics, etc...) for people who do need portable code (the main reason for bswap).

I think languages are starting to take the place of platform independent interfaces, and my personal opinion is that bswap is fairly low hanging fruit. Given that one of the stated goals of C is portability, I think it fits well within the mandate.

[1] http://commandcenter.blogspot.com/2012/04/byte-order-fallacy...

This doesn't say anything about pointer arithmetic on pointers to raw memory though. For example, using an mmap file, there isn't any object, and there aren't any bounds.

I can see that a non-linear address space doesn't imply a strict weak ordering, but this still seems to be an implementation defined detail. It doesn't imply anything about pointer arithmetic overflow.

For example, consider x86 segments. Is there a reason why you would use negative offsets? Given a segment address, the number of representable values is identical whether the offset is strictly positive, or negative with a shifted segment address (assuming two's compliment).

Accessing beyond bounds is undefined, but leaving pointer arithmetic outside of objects undefined would preclude a lot. For example, building an OS page table or DMA, or RDMA, or MMIO, etc...

Non-linear address spaces shouldn't affect pointer arithmetic though, unless I'm misunderstanding something. Otherwise, I guess the implication is that there are systems or implementations that rely on negative pointers; in which case I would think it should be up to the implementation.

Pointer arithmetic overflow frightens and confuses me. Does anyone know why it's treated differently than unsigned arithmetic?

This is why I avoid allocating large VLAs, and using them in deep call stacks in general. There's a diminishing return for allocating on the stack beyond a certain point anyway (roughly around a page).

Having a mechanism to abstract this might be nice, but these are things people should hopefully be aware of before using VLAs. std::dynarray has been a bit polarizing though.

One minor thing that should hopefully be considered... a %b/%B conversion for printf et al.

It's useful to print binary representations of things (debugging, conversion, etc...). A number of libc implementations support it as an extension. Forcing people to re-implement it outside of printf is a bit obnoxious considering how simple it is, and that there are already hexadecimal and octal conversions.

I thought the book was great. It's a quick read, but easily increased what I could do with tmux. I can't think of much more it really needs. Maybe cover stuff like if-shell? The true-color patch might also be worth mention.

FYI, there's a slight bug with the xclip copy binding, but it's pretty easily fixed (bind C-c run "/usr/bin/tmux save-buffer - | /usr/bin/xclip -i -sel clipboard >/dev/null").

Just using tmux to get more than one terminal was really only a fraction of the stuff I could use it for. My terminal launches in XMonad use tmux by default now.

As far as the copy stuff, I'm talking about pipe or line dividers in terminal apps (e.g. mutt, ncmpcpp, etc... If whatever I'm trying to copy covers more than one line, tmux will copy over the divider which is painful.

You're book is great for getting up to speed with tmux basics. The intro to tmuxinator was also pretty helpful.

One of the bigger things I think people miss is copying text into and out of tmux panes, including to the clipboard. This saves me a lot of time switching between windows often, especially using the vi keybindings. Although one thing I wish tmux did better was handling things like dividers.

SSE performance is better than x87, for a number of reasons. Latency and throughput are generally better, but SSE also supports SIMD which allows more than one op per instruction. SSE also has more registers (x87 only has 8 80bit compared to at least 16 128bit). If I'm not mistaken, the number of available execution units with SSE is also larger, which means more opportunities for instruction level parallelism.

These are why modern compilers don't emit x87 for floating point.