skysight-inc/HackerNews huggingface dataset:
>They seem to solve a good portion of the problems.

The problem is that human beings generally hate them.

For a good example of this (and why), check out (http://slatestarcodex.com/2017/03/16/book-review-seeing-like...).
So keep it, and use it only for rendezvous for better systems, and for the automated transactional bullets that email is principally used for today.
Take a spring cleaning day every quarter. Review notes, think, use mind maps or outlines to distill whatever you are thinking of.
I don't think we need serious secure messengers, because we mostly don't need to send secure messages.

Email is "mail on the internet". Mail isn't secure. We use mail everywhere for everything. Occasionally there can be some security problems with conventional mail, but they're fairly rare and we tend to get on with life. And if you need to send a secret via the mail, you can do what the military has been doing for 2,000 years and encrypt your message contents. So I agree, we should stop freaking out about mail.

But we need a secure messaging system? We didn't seem to need it for the post. For the average hacker it's nearly impossible to break into modern messaging systems, centralized and encrypted as they are today. And a lot of us live in free societies where repressive regimes don't legally get to spy on our messages.

Now, this will change in 20 years when China starts spreading its form of Communism around the world similar to how we spread Democracy, as more nations will start adopting internet censorship. But as we've seen with a lot of censorship-circumvention technology, the authorities are pretty successful at blocking or banning the means, and providing state-sponsored replacements when they can't effectively do that.

If you want someone to deliver you a secret today, nearly any messaging service will do. If you don't want to rely on a particular central messaging service, you have to go back to PKI or public-key crypto, which nobody wants to do. Basically, we have "good enough" solutions today, and we have better solutions that people can use if they have to. So I don't think a new secure messaging system is warranted.
Crypto is a quick grab for cash, and this is the most blatant about it. Great Job.
If you "set -e", you probably also want to "set pipefail". By default, a pipeline returns the return value of the last element. pipefail means that if any element of the pipeline fails, then the pipeline as a whole will fail. I discovered this the hard way when I had:

make run-asan-test | c++filt

And even if the tests failed, the script would succeed.
You're confusing client-server secure transport with secure messaging, which is not at all the same thing. Yes: you can ensure a specific SMTP (or IMAP) client connection is encrypted with TLS. But email is store-and-forward. What you can't do is ensure that a given message is encrypted at every hop, let alone end-to-end, where only the sender and receiver can read it.

Obviously, that's the point of layering OpenPGP on top of email. But, like I said: that's opt-in, with plaintext as a default. We would never accept that design in a secure messenger system.
Places where land is cheap have bad transit and low population density. That's both bad for network effects and bad for the environment.
Sorry, I probably was too sensitive to the reply. Mea culpa.

> I don't know if there are any other alternatives

In my opinion, there will likely never be anything to ensure nothing was done, hence why (well that plus the example you gave) I incorrectly assumed you were backhandedly making an insult rather than asking for a real discussion on it.
To be fair, Coffee Lake is presumably faster/better and not more vulnerable than other chips [0]. If you have to mitigate anyway, and you're desperate to get back to pre-mitigation performance parity, releasing a faster chip that still requires mitigation could be a reasonable option.

[0] Caveat: Skylake and later are extra-vulnerable to Spectre because they have even more aggressive speculative execution, but fortunately, the IBRS microcode update is roughly equally performant as retpoline on Skylake+ only.
I agree about your assessment of the article, but I think you've missed the question of the right abstraction. Why does SF/Bay area need affordable housing? Sure, the world needs affordable housing, but why does the Bay Area? Why is the right level for affordable housing the region, and not the state or the country or, heck, in the other direction the suburb or street? Why is this city region the correct abstraction?

We've reached a point where certain places - London, NYC, San Francisco, Singapore, Hong Kong and perhaps even Shanghai - are so large and economically important that the idea they should include affordable housing, when there are alternatives that are much more financially effective, seems a little off to me.

I'm not sure why anyone would want to live in affordable housing in SF, when everything is so expensive. Wouldn't it make more sense to move whole family groups to Portland, for the same prices as one of those families could live in SF? Not even that far, to Oakland maybe, or the outskirts.

And why is the right abstraction one house? A policy of whole family moves, or community moves so people keep their connections, would seem like a more sensible idea. People stay in areas that are awful often because they don't want to lose those connections - which I 100% get. So why not move groups of people - willingly - so they have the best of both worlds?
I haven’t dug too much, but I believe at my work, we run a server that hosts all our jars, and is the source of truth for all our builds. Nothing that’s been checked in goes straight to the Internet (you can add new dependencies to uncommitted code). And we’re only ~30 devs.
It redirects from a google search.
Not scrap. They do evidence an intention to pay. They are an acknowledgement of the debt. The individual clauses may be struck as illegal, but the documemt and signatures are still a thing.
> Taken to its logical extreme: If people could teleport from one place to another instantly, there'd be almost no value at all to congested urban spaces.

So, like if we start being able to do our jobs in VR?
The thing I wished I had learned earlier is "quick and dirty assertions". If you write lots of functions in Bash, you quickly end up getting tripped up by cases where an argument is omitted and the function does something totally batshit given the missing (empty string) argument. Now, the canonical way to handle this is to put validators on your input, (and make sure those validators don't crash with cryptic errors if someone calling your function is using "set -u") like so:

function() myfunc {
local foo="${1:-}"
if [ -z "$foo" ]; then
echo "Invalid first parameter!" >&2
return 127
fi
...
}

...but man, that's time consuming when you have lots of parameters.

Instead, the quick and dirty way is to just "assert" via [parameter expansion](https://www.gnu.org/software/bash/manual/html_node/Shell-Par...):

function myfunc() {
local foo="${1:?First parameter must be provided}"
...
}

Much quicker, especially when throwing things together in a hurry. It has a gotcha, though: ":?" assertion doesn't cause a function to return early, it shuts down the whole interpreter after outputting the error. So it's more like a true assert() statement than an input validator. If you'd only ever call your function in a subshell, this won't matter (because the subshell will exit early with a nonzero code, big deal), but otherwise it can be a nasty surprise to users when an argument-validation issue inside a function shuts the program down. Then again, the "return 127" in the first example would also shut the program down if someone was using "set -e".

...and while we're on the subject of "set -e", I think that the ["unofficial Bash strict mode"](http://redsymbol.net/articles/unofficial-bash-strict-mode/) (putting "set -euo pipefail" and "IFS=$'\n\t'" at the top of your scripts) has been a bigger bug-prevention/rapid development aide to me than anything else. To be clear, I think it's a means of detecting some kinds of bugs. I've read Wooledge and others' objections to those patterns, especially "set -e", and agree with the point that this does not make your programs objectively safer and shouldn't be counted on as a crutch. Then again, neither does a linter, but it still helps you detect and avoid some kinds of bugs, so why not use it?
Well since someone submitted us here with no apparent reason or context, allow me to provide something of interest. (primary contributor of bleve here)

Just recently we merged support a new experimental index scheme called 'scorch'. This new index scheme is designed from the ground up to reduce index size and improve performance. It features:

- a segment based approach, much like Lucene

- vellum FTS for the term dictionary -
https://github.com/couchbase/vellum

- roaring bitmaps for the postings lists - https://github.com/RoaringBitmap/roaring

- and compressed chunked integer storage for all the posting details

It's still experimental at this point, but shows considerable indexing speedup, index size reduction, and similar query performance to the old index format used today.

The code for this new index scheme can be found here: https://github.com/blevesearch/bleve/tree/master/index/scorc...
docker-compose trades a better initial UX for far less flexibility and, funnily enough, higher practical complexity in the long run. It's great if you want to get from zero to MVP with as little thinking about what your infrastructure needs will be as possible. It's pretty awful, however, when you want to truly productionalize what you've done and you find out that in order to do so you'll have to use the newest Compose format, and your docker-compose.yml (and possibly additional supporting Compose) files are not at all easier to read or simpler to write than e.g. k8s objects in YAML.
That would probably help some. Really, they should just flicker faster. There’s no reason not to do PWM at a kHz or 10, and nobody is going to see that flickering.
No, an LPR can only be denied entrance if:

(a) They are regarded as seeking admission and they are found inadmissible. Refusing to unlock their device will not make an LPR regarded as seeking admission as it’s not a reason listed in INA 101 (a)(13)(C): https://www.uscis.gov/ilink/docView/SLB/HTML/SLB/0-0-0-1/0-0...

(b) They are deportable. Simply refusing to unlock a device in itself will not make someone deportable as it’s not listed in INA 237 “General Classes of Deportable Aliens”: https://www.uscis.gov/ilink/docView/SLB/HTML/SLB/0-0-0-1/0-0...
Explanations of special relativity, explorable or otherwise, are dime a dozen. Try explaining general relativity in this fashion. Try explaining cosmology in this fashion.
Yep. I wonder if you give up some small amount of power efficiency at higher frequency, but it shouldn’t be much.
An individual server-to-server communication occurs in milliseconds, so the fact that messages do not arrive frequently is completely irrelevant. It's simply because Moxie -- someone likely to be immune to your kind of negativism -- has not seen fit to work on the problem, given that messaging with an asynchronous chat format fits the general trend of user adoption. Someday I suspect he'll come around on it, I hope.
Sometimes your project becomes bigger than you, and perhaps private ownership isn't the best way to handle that anymore:

http://magarshak.com/blog/?tag=identity

Well, Q allows you to choose between “each individual publishes their own stream” and some degree of “centralized publishing” by management teams of groups. So who should publish a stream, the individual or the group?

If the individual - the risk is that the individual may have too much power over others who come to rely on the stream. They may suddenly stop publishing it, or cut off access to everyone, which would hurt many people. (I define hurt in terms of needs or strong expectations of people that form over time.)

If the group - then managers may come and go, but the risk is that if the group is too big, it may be out of touch with the individuals. The bigger risk is that the individuals are forced to go along with the group, which may also create a lot of frustration. For instance, the group may give rise to into three sub-groups. They are deciding where to go, but some people want to go bowling, others want to go to the movies, others want to volunteer in a soup kitchen. Even though everyone belongs to the group. Who should publish these activities?

So I think when it comes to publishing streams that others can join, there should be some combination of groups and individuals. And it should reflect the best practices of what happens in the real world: one person starts a group that may later become bigger than him. Then this group grows, gets managers etc. After a while this person may leave. In the future, other individuals may want to start their own groups and invite some members of the old group to join. They may establish relationships between each other, subscribe to each other’s streams, pay each other money, etc.
Using Segmentation to Improve Click Rate and Increase Sales
http://www.benchmade.com/
This does not conflict with anything I said. Yearly updates != monthly updates.

And even then you don't always have to update for each new iOS release unless you intend to make use of new features.

I had an app on the AppStore for 3 years without updates before Apple said 'this app needs updating or we will remove it from the Appstore.
Big cities across the world have seen a massive spike in price in the last few decades. Much of this is due to tax reasons and speculation (both foreign and domestic).

End tax breaks for real estate owners and end the ability to speculate on home prices on a large scale, and housing will become much more affordable.

Or institute a Land Tax, which incentivizes high levels of housing density and housing availability. A land tax is also the most efficient type of tax that exists, and acts as an moderate wealth equalizer.
LED light output isn’t linear in power input though. PWM allows you to drive the LED in its most efficient regime no matter how much brightness you want.
The "The right to be forgotten" applies to private information made public against a person's will, such as revenge porn or showing up in search engine listings. It does not apply to content willing contributed to a public community, like HN, reddit or Miiverse. What facebook does still applies, though, because a lot of the data they use, sell and trade is data their users think is private.
Well... No. the left-pad function is 11 lines. The source code, as it was back then, according to that register article, was like this:

function leftpad (str, len, ch) {

str = String(str);

var i = -1;

if (!ch && ch !== 0) ch = ' ';

len = len - str.length;

while (++i < len) {
str = ch + str;
}

return str;

}

But yes, packages broke because of what _could_ have been implemented in one line (ignoring the two lines for the function signature and closing curly).
Yes, some people prefer cities, but we have to ask whether those are the people fueling urban growth.

In San Francisco, I suspect it’s mostly
jobs, not love for the city, that is causing growth and fueling housing price increases.
I love signal and kinda-sorta agree, but

a) Right now Signal is oriented around your hpone # and while most people have phones, they come at a cost, are less easy to acquire than an email address, and much less anonymous

b) Signal (and slack and so on) organize conversations around individuals and groups, rather than around subject. That's OK for personal contacts (with whom you have conversational context) but not so great for many other contexts where you'd like things structured by subject
I think the timing is pretty perfect for a RISC-V open eco-system to flourish in a Cambrian manner.

With silicon scaling laws getting walls, Intel's ability to have an efficient general purpose CPU for every workload is fading. The only way to provide better performance is to provide specialization, now.

Processing will specialize in the following:

* databases: SQL projections in special hardware data slicing CPU instructions. Hardware-accelerated hashing, sorting, filtering.

* dynamic languages: Special code caching for JITted code. Memory models that won't have to be emulated. Memory barriers and copy on write to help the GCs do the work.

* AI: We're already seeing this with Google's TPUs: Low precision tensor operations. We're going to see more specializations inside this segment too. Tensorflow today has CPU, GPU and TPU backends. In a stable high volume configuration such as vision for an autonomous car, why not provide a fourth backend for a Tensorflow pipeline: VHDL/Scala?

* IoT/Sensors: Extremely low power modes, on-chip LoRa.

* Network: this is already happening with microsoft using FPGAs to help do the routing. Once settled, some use cases will have their silicon edition.

----

This will lead to a thining of the margins of Intel, NVidia and ARM, to the fragmentation of the monopolies, and less money will go to the lawyers.
OK, fair point.

What are the most significant dangers you face, if I may pry? What's worse than snakes and spiders on a weekly basis?
Shameless plug! I have a similar Python project but focused on building native applications without actually writing a single line of UI code. I call it Gooey[1]! It was front page on HN a few years ago ^_^

The next version is currently in RC1 and brings support for in-UI validation/error messages, better layout customization[2], new widget types, and more!

I'm trying to recruit a few more people to test the current release branch[3] :)

[1] https://github.com/chriskiehl/Gooey.
[2] https://user-images.githubusercontent.com/1408720/34464824-c...
[3] https://github.com/chriskiehl/Gooey/tree/rc1
An individual server-to-server communication happens in milliseconds, but these systems layer on top of existing email clients, which do not have a polling interval of milliseconds.

I wouldn't hold your breath on email crypto from Moxie.
I probably miscommunicated as well. I could see you got it, and my main (attempted) contribution was to point out the things required prior to increased housing (when there are large numbers of empty units) which would make the problem easier to deal with.
This is a very interesting way to look at the issue.

Income source strikes me as the most significant challenge. How will the citizens of these communities earn money? In addition to remote work, local manufacturing, education, healthcare, public safety, tourism, and service industry can help fill the gap. Quite a master planning challenge though!

Access to natural resources is a challenge, but that challenge might spark solutions we’ll need other places on Earth and as we colonize the Moon and Mars. People already choose to live in many inhospitable regions, depending on purchased water or routinely damaged by predictably destructive weather patterns (I’ve often wondered why wealthy New York financial firms don’t relocate somewhere sunny).

Sustainability is another question I have. Is it more sustainable for us to build up in cities than to set up distributed towns? Do we need to pivot how we aspire to live and what we aspire to own from standalone houses to dense high rise units?
There are other OSes and affected companies beyond the ones who were chosen to receive advance warning.

Imagine how it would work out in your airbag analogy if only Toyota and GM knew, and they withheld information for months while they worked on their own fixes, meanwhile the public remains in danger and other automakers have no chance to implement their own recall plans.
Ok and? How does what you said contradict what I said? I didn't say there were no problems.
No, that's the entire point. They need almost nothing at all but the ability to run code fast in a loop with memory calls. The entire point is that they bypass privilege checks.
AFAIU (prolly not much), GDP measures money that comes and goes to/from a country. If, let's say, products/services were exchanged directly, without moving money, that wouldn't be counted; OTOH, if certain country, say the US, gave money to another country only to buy products from US companies, that would count doubly... Which is why it's really bad as a tool for comparing wealth of nations.

Please correct me if I'm wrong.
If you design your infrastructure and choose your tooling well, then containerized (not "dockerized") software is far less dependent upon configuration management; indeed, using Chef/Puppet/etc can be completely unnecessary for the containerized workload. To be clear, however, there is absolutely still a need for the now-traditional configuration management layer at the level of the hosts running your containerized workloads. What's kind of exciting about this is that the giant spaghetti madness that our configuration management repo has become—and I'm pretty sure it's not just us ;-)— at our org is going to be reduced in complexity and LOC by probably an order of magnitude as we transition to Kubernetes-based infrastructure.
How easy is it to generate the level from the set of tiles?
FYI, switchmode supplies don't need microprocessors. Many are entirely analog, most of the rest use a small amount of digital logic to control the switching. EG check out the LT3574 datasheet[1] pg 6: the only digital logic is the master latch, and it's just doing the "thermostat-style" switching I mentioned above. Or for an even more basic system: the ringing choke converter[2]. Lots of cheap power supplies use these because they are very simple and require no digital circuitry.

Edit: also to get a given voltage out of a microprocessor, you just use an analog-to-digital converter (ADC). Some have them built in, others are external. I like the AD9850 for hobby work, as it has a high resolution and is quite fast. If you need a large voltage range there are ADCs available for that, or you can amplify the signal from a lower voltage one.

WRT your issues with sensitivity to SMPS, it probably is audible noise. See if Screen Tunes[3] causes symptoms, it causes audible (but quiet) coil whine of varying frequency on most monitors I've tried. Your issues are unlikely to be directly caused by RF EM, but the side effects of the systems that generate such signals are often detectable by people.

[1] http://cds.linear.com/docs/en/datasheet/3574f.pdf
[2] http://mmcircuit.com/understand-rcc-smps/
[3] https://thume.ca/screentunes/
Applying the UV alight would kill the ‘good’ bacteria and organisms the living water fans are so interested in ingesting.
My friend loves benchmade, but they are out of my price range by a lot. I'm also leaning towards something more like a swiss army knife.
Why depressing? Remember when bands prohibited recording devices from their concerts? They are now finally realizing that fans with cameras (video and still) can do more for publicity than a bloated advertising budget, something which newer bands don't have access to.
> The kernel does a great job in maintaining backwards compatibility, the rest of the stack not so much...
reply

No disagreement. But so far I did not encounter any issues with other parts of Linux other than the kernel. So the rest of the stack seems to do quite well.
Do you think the communication channel will persist beyond the current vulnerability? E.g. give it a name, allow other cloud providers to join?