News for hackers. Stuff that matters.

uxcn

Re:How To Open and Manipulate Large CSV Files On A Mac on Tuesday November 05, 2019 @01:19AM (#21450136)
awk, sed, cut, etc... are excellent as long as the format is regular and you only need to process the file once
Re:ASML Buys Stake in Carl Zeiss Unit for $1.1B on Friday November 04, 2016 @09:09AM (#12872228)
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?

Re:Zcash begins on Friday October 28, 2016 @03:50PM (#12819998)
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).
Re:IRC v3 on Sunday October 09, 2016 @08:54PM (#12674411)
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.
Re:IRC v3 on Sunday October 09, 2016 @02:29PM (#12672560)
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-...

Re:ORWL – The first open source, physically secure computer on Thursday September 29, 2016 @05:17PM (#12608829)
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...

Re:ORWL – The first open source, physically secure computer on Thursday September 29, 2016 @01:45PM (#12607246)
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?

Re:What if the aliens we are seeking are AI? on Monday September 26, 2016 @12:13AM (#12579172)
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

Re:What if the aliens we are seeking are AI? on Sunday September 25, 2016 @10:35PM (#12578863)
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.

Re:What if the aliens we are seeking are AI? on Sunday September 25, 2016 @10:15PM (#12578782)
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.

Re:What if the aliens we are seeking are AI? on Sunday September 25, 2016 @10:02PM (#12578732)
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?

Re:What if the aliens we are seeking are AI? on Sunday September 25, 2016 @09:40PM (#12578640)
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?

Re:JRE 8 needs more codecache than before on Thursday September 15, 2016 @05:44PM (#12510083)
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.

Re:JRE 8 needs more codecache than before on Thursday September 15, 2016 @01:59PM (#12508314)
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.
This seems a bit precarious.
Re:Google’s Self-Driving Car Project Is Losing Out to Rivals on Monday September 12, 2016 @03:23PM (#12482821)
I would be genuinely curious what the development methodologies for Chauffeur look like, if anyone can point me in the right direction.
Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @07:35PM (#11308569)
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...

Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @06:45PM (#11308245)
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.
Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @06:41PM (#11308220)
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).

Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @04:48PM (#11307479)
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...
Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @04:42PM (#11307427)
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.
Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @02:17PM (#11306354)
Pointer arithmetic overflow frightens and confuses me. Does anyone know why it's treated differently than unsigned arithmetic?
Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @02:10PM (#11306301)
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.

Re:C – Preliminary C2x Charter on Thursday March 17, 2016 @02:02PM (#11306234)
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.

Re:Ditching tmux on Tuesday March 15, 2016 @12:04AM (#11287347)
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.

Re:Ditching tmux on Monday March 14, 2016 @11:27PM (#11287247)
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.

Re:Is this prime? on Monday March 14, 2016 @05:26PM (#11285691)
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.

Older »