uxcn
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?
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.
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-...
I'm a bit surprised the quantum algorithm only gives a polynomial speedup.
[1] https://en.wikipedia.org/wiki/Observable_universe#Matter_con...
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?
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.
My point is still that life less intelligent than us has nothing to communicate to us that we would care to respond to.
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.
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?
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?
I have no idea how many other people actually use it though.
Even with those systems working exactly as designed, there are some serious liability questions I don't think anyone has really answered yet.
“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.
This seems a bit precarious.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...
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).
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.
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.
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.
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.
These are why modern compilers don't emit x87 for floating point.