Hacker Newsnew | past | comments | ask | show | jobs | submit | more linuxguy2's commentslogin

I looked into this last month when they posted this "job description" and was sorely disappointed. It seems the sum total of what they have is:

* A slack that might see a new message every 12 hours.

* A github

* A domain

Nowhere did I see anything that actually looks like a company, has money to pay anyone or even had a whitepaper that describes what this new technology is going to do or how it'll do it.

Initial deploy servers numbering 100k+? Yeah right, I don't think there's even 1 running.


I thought I had seen this before....

Previous discussion: https://news.ycombinator.com/item?id=14764125

It even links to the same site and the blog was posted by the same guy. I wonder why he's recycling content.


The financial situation of Nautilus is not the best[0] which might explain why they recycle content.

[0]: https://nautil.us/blog/a-letter-from-the-publisher-of-nautil...


He posts a lot of content, possibly he just forgot he posted again


New accounts are green. Seems that two weeks is the threshold for showing up normal.


I think moderators can bypass that as well. I'm fairly sure I've seen accounts go from green to normal within hours when it was the author of some paper or project that someone submitted finding out they are on HN and making an account to answer questions. I suspect moderators authenticated the user separately, or used the comments to do so if it was completely obvious.


These reports are always well written and interesting reads. Thanks for continually producing them!


Thank you! Andy (the guy that writes them) will be happy to hear the kudos!


Who pays the power bill?


The ghosts.


in soviet russia, the power bill pays you


They're talking about the novel, 1984.

https://en.wikipedia.org/wiki/Nineteen_Eighty-Four


Whoosh! It was a joke.


Is this different than cells self-impaling on asbestos fibers because the Si nano-wires are smaller? In the video from TFA it showed some cells with wires going through them that were longer than the cell's diameter.


This was my question as well. There are some studies showing that carbon nanotubes can be as dangerous as asbestos, so it seems likely silicon nanowires could be as well:

https://www.scientificamerican.com/article/carbon-nanotube-d...

However, if they can make the nanowires shorter than the minimum dimension of a human cell then it likely wouldn't cause the same sort of cancers as asbestos.


>if they can make the nanowires shorter than the minimum dimension of a human cell then it likely wouldn't cause the same sort of cancers as asbestos.

It seems like a tiny knife floating around inside the cell would still cause problems, including genetic damage.

Or did you mean it wouldn't cause the same sort of cancers, but rather new, exciting cancers? :)


I don't think the two other responders to your question quite have the whole answer so I'm going to chime in. Warning: I'm not a kernel developer, have only read the article and work with linux daily.

To answer your second question, this doesn't have anything to do with disk changes/inotify/etc that a program would use. My understanding is that currently \many\ IO devices respond to the kernel's request for data by triggering an interrupt that then takes time for the kernel to get to for reading. The interrupt process can be a bit slow leading to latency when waiting for the disk to respond. The new system, rather than waiting for an interrupt, continuously checks the driver for new data and as it doesn't rely on an interrupt can achieve far better latency. Lower latency means more operation per second.

With spinning disks who are only able to do <200 operations per second with latencies around 5ms this won't have much of an effect but with SSD who are able to do >2000 operations per second with latencies around 0.5ms trimming off 0.1ms per operation (made that number up) via polling rather than waiting on an interrupt can mean about 20% more operations per second.


I fear, this may impact negatively in terms of power. If I'm not wrong, the point of having interrupts was to save CPU cycles wasted on checking status, i.e. polling. Overall, I think it would be interesting to see some benchmarks on real scenarios.

EDIT: Thinking a bit more about it, interrupts were introduced when CPU were much more slower than they are now. So, the tradeoff I'm thinking isn't that bad.


The power difference may actually be immeasurable, or even an improvement on some systems. Switching from one power state into a lower-power state may actually involve one-time energy payments, which are eventually negated by the power savings as time progresses. In an extreme scenario, a core might power-down its cache to reduce leakage current, which involves sending all of its pending writes onto some bus, which is costly, and then it'll be reading a lot of data back in from elsewhere once it is powered back on as it refills the cache.

In the worst case, you might spend more time and energy switching between power states than you actually spend in a lower power state.

But indeed, it does seem counter-intuitive even with that, as there are often power mode changes available that would pay off in just a few microseconds. It sounds to me like x86 may suffer from a limited IRQ system - there are other systems out there in which IRQ overhead is < 10 cycles.


Aha. Very interesting. Thanks so much for taking the time to spell that out for me.


Yes, I think you missed that. From the article:

"It takes less than five seconds for your address to be harvested and scanned. The entire scan takes less than one second and scans over 100 common TCP and UDP ports. "


OK. I'd like to see a full packet capture. And technically, the address was not 'harvested'. He gave it to them when he sent them packets. The story strikes me as very dramatic and over the top because of statements such as that.


Look in to what shodan is, its a service dedicated to portscanning the internet. With ipv4 you can easily scan every ip, with ipv6 you need some mechanism to discover addresses. This very much looks like they joined the ntp pool soley to harvest and portscan addresses.


The very last line of the article:

> For all its benefits, there's also a downside to having large prefetch sizes: there's the chance of

Is the unfinished sentence a joke about a chance of not reading data completely or did the editor not include something?


The article isn't complete, but I added a new paragraph this morning that completes the sentence you mention.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: