skysight-inc/HackerNews huggingface dataset:
Crimes require victims.
It'd make no difference, as the keys in question are replaceable via microcode updates and the microcode version is included in the remote attestations.

SGX doesn't really give Intel "control" in the sense of taking away existing freedoms. It's a new feature. You can always elect not to use it, or not to use software that uses it.
Roswell: a Lisp installer and launcher for major environment that just works
Not sure about how it was in the pre-DOJ days, but in recent Microsoft history there is a company policy not to ship non-OS binaries that use private Windows APIs.
Well, lots of drugs are sold for cash. Cash is issued by the Fed. Can it be sued for facilitating drug crime?
> Java awt is a descendant of Tk (oak).

That's not accurate. Tk did predate Java by a few years and Tk was fairly well known in the X-Windows/Suns/Unix workstation circles so it may have had a slight influence but AWT never shared any code with Tk.
A lot of ARM SoCs, particularly in the mobile world, have always had features like this. Apple even explicitly advertises it as a security feature on their iDevices. I think the difference here is because x86/PC has traditionally been one of the more open platforms, so attempts at locking it down are more strongly opposed. The PC is one of the few remaining computing devices where you can still inspect, modify, and develop with relative freedom.
+1. For me, and I have used orgmode, onenote, and evernote and for me, there is nothing better.
Actually, the O(n^2) thing is correct for an NFA simulation that tracks states not paths. While there might be O(2^n) paths, there are n states you can be in at any one point.

https://swtch.com/~rsc/regexp/regexp1.html
I used to use DarkBasic from seeing it first time in PC Gamer magazine around 99 or 00, so this is great news.
The argument that this article makes is somewhat muddled, but if I'm understanding correctly: child prodigies don't end up advancing their fields to the extent that their early talent might suggest because by and large they're not original/creative, which is because they learned at an early age to conform to well-defined standards of success instead of pushing the envelope. So we get "excellent sheep," or masters of using ordinary methods who still receive nice but ordinary results.

But 0.5% of the Westinghouse pool winning Nobels is still far better than the population average. What this article tells me is something that seems pretty obvious: that raw ability is correlated to being recognized by society for acts of genius, but so are other things, including both the "thinking out of the box"-ness that the author trumpets as well as entirely extrinsic and random factors (ie the Nobel committee likes you, your style of work or area of focus happens to align with or be amplified by a prevailing intellectual trend, etc). Prodigies don't always succeed in pushing the enelope because it's vanishingly unlikely for anyone to do so; they still do a sight better at it than most.
Slightly off-topic.

This is why we went from using AWS to using our own servers based on commodity hardware.

We went with mattermost instead of slack since we wanted to control our own data.

Of'course it depends on how talented your developers are and how much management want to bankroll your long term outlook - which unfortunately is not the case for many companies out there.
-Apps, mega niches, are the future! (Yeap)

-Don't let any one app to be the sole place a user gets his content (I'm with you here as I didn't create Facebook)

-Parse is no more (I read that somewhere too)

-Now you can focus on leveraging an existing platform to bring engaging content to your users. (What if I want to service a mega niche that doesn't exist or generally wish to be foolish enough to believe I can compete with my idea? Wouldn't it be convenient to leverage a Backend as a service like parse? Shame they shutdown)
Reading poettering's response (https://github.com/systemd/systemd/issues/2402) I'm left feeling like he needs a thorough "Mauro, SHUT THE F* UP" response from Linus himself (https://lkml.org/lkml/2012/12/23/75)
> The support of fancy features like backtracking does not cause any degradation of performance for simple regular expressions.

Well, backtracking is how you implement your engine. So "simple" regular expressions that don't use any of the features backtracking provides (like backreferences) will cause exponential complexity, like:

a?a?a?a?aaaa for a string "aaaa"
Why stop at 2 gigabits/sec? Why not go all the way up to 10g, 40g, or even 100g? It's not like rain or fog or other atmospheric effects will cause much problem for free space optics or tighter band RF (e.g. 60-90ghz millimeter wave) communication in space, so was it a physical or budget limitation? At these higher throughputs, the same relay network might be usable for other things in the future, such as streaming terapixel video...
If no workers are needed, I don't see how you have worked owned cooperatives.
And I subscribed to a mailing list years ago that suddenly went TLS-mandatory (for incoming email---it doesn't demand TLS when sending email) and now I can't even unsubscribe from the list.
We detached this subthread from https://news.ycombinator.com/item?id=11006266 and marked it off-topic.
> Imagine being able to download just one build tool that by
> default allows you to write something like
> ‘jsc /some/js/dir -o /some/build/dir –enable-jsx’

$ npm install --save browserify babelify babel-preset-es2015 babel-preset-react
$ browserify -t [ babelify --presets [ es2015 react ] ] \
main.js -o public/bundle.js

To incrementally recompile when a file changes: `npm install --save watchify` and replace `browserify` with `watchify` above.

There are sets of tools that compose well and are easy to set up. I think developers hear about all these new techniques and think they need all of them, but it's much more important to know what you don't need and how to incrementally add pieces in small steps only when you need them and not before.
I dont see where in this thread that became the topic, rather it's been about cookies in CDNs. You still seem to think that CDNs are only used for caching when that is just one of their features. You can also use them for security, for example, without using any caching at all.

If you need to authorize every single request (even to a static file) which means that every single request is unique, then this is obviously not a good use case for an edge server cache. You can still cache things in the browser with cache headers and continue using the CDN to proxy the full request with cookies to the origin. This doesn't add much latency and can sometimes decrease it because the CDN will keep faster connections open to the origin.

However, most CDNs today also offer their own access controls either with cookies or url tokens so you can do authorization at the CDN edge instead of the origin.

And yes, you can use the CDN to cache static files and just proxy requests to pages. Usually private information that requires authentication is in the webpage and the static files like javascript, css and images dont need protection.
The thing I find particularly hard to grok is that they came up with this idea of putting disk-specific boot information on the motherboard. Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.

Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.
The protocol name is part of the URL, so it is possible and technically valid that the https version leads to different content than the http version. Some things are certainly different, for example if there are ads and other linked resources on the https page, they all need to go through https, while on http page, there is no such requirement.
It's poorly phrased, but I think he is agreeing with you.
Many articles try to imply that the lead came from the new water supplier; in fact, it leached from lead pipes the existing system used as its water mains.

I haven't read any articles which say that. The consistent narrative has been that that the (drastically) increased lead levels by late 2014 resulted from an influx of corrosive agents into the municipal water system (perhaps exacerbated by a decision not to add anti-corrosive agents to counteract this effect).

I haven't read any source which claims the increased lead levels "came from the new water supplier." They all seem quite clear as to the basic cause-and-effect relationship, in fact.
Ask HN: What are the best open source tools you use in your organization?
That's absurd. The effects of the heightened awareness the Internet has sustained are immeasurable and omnipresent. The washing machine just tells a cleaner story.

SMS+social feeds have created an entirely new way of knowing which is unbounded by space or fixed infrastructure.
> You could be easily reading at 1GB+/sec and pushing 10-20Gbps to NICs, depending on the hardware.

Python is easily able to push this much data but I have the impression that the problem are the performance-hogging libraries. In my case I had to write my own HTTP client implementation for Python to get such speeds. Python is not the problem you just need to avoid unnecessary LoCs.
Time to do some fuzzing experiments...
The feds also actively try to combat drug sales. LR made little to no efforts to do so.

I agree with what you're saying but I disagree with your example.
Yeah, I remember in 2000ish doing our first "real-life software application" in my undergrad. Just a simple desktop UI for Amazon.

Everybody else used Java because that's all they knew, and it killed them. 3 man teams and they couldn't make it work.

I used Python with TkInter and it was a breeze. Not quite as easy as VB6 (Microsoft doesn't get enough credit for stealing Delphi's good ideas), but they'd specifically said I couldn't use that. I had only 1 teammate and he spent his whole time working on Amazon interface code - sending/receiving XML and getting them into useful python objects.

Later on in my carreer I learned Web stacks and my brain hurt... but that might be because I started with the horrible abomination of ASP.Net webforms.

HTML+CSS+Javascript only manages to be a functional application framework thanks to the weight of the entire computing industry. The trillions(?) spent on this bullcrap is just silly. The wrong platform won because it was the lowest common denominator - everybody already had a browser.
The web is controlled by players who have shifting agendas. There's always at least one player that wants to advance the web, because they are doing poorly in the native OS market (or some portion of it). There's always at least one other that wants to keep web technology stagnant, because they are doing well in the native OS market. These players switch roles as the market evolves. The power in the web is that once you have a critical mass of content that requires a certain feature, browser makers have very strong incentives to support that feature, and very strong disincentives to not support it (such as undermining their market share, and thus control over future web evolution). Which means that progress is pretty much monotonic, but also very path-dependent. Hence why the technology is often such an awkward fit for its current uses. It also means that the web api will always lag behind the richest native apis, but that's how all technology works, and must work if there is to be progress; the cutting-edge is always non-standard experimentation.

In terms of controlling presentation, WebAssembly, HTML canvas, and WebGL are conspiring to bust the monopoly of the Javascript/HTML/DOM model. Look at this: http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt... (takes a while to load, worked on Chrome for me despite warning). It's a full blown Qt app running in the web browser. There's obviously a lot of kinks to sort out, like the massive loading times, but it's not that far from being viable.

WebAssembly and the ecosystem that will grow around it (to some extent, this already happened with asm.js and Emscripten) are game-changers for the web because they shift the burden, i.e. developing for an inferior platform designed by a committee full of bad-faith actors, from every single app developer to the compiler and core-library developers. Of course, this will lead to inefficiencies like drawing with Qt inside a VM inside a web browser that's itself drawn using Qt. And so smart browser vendors will figure out how to optimize, thus some web apps will work much better on their browsers. This will force the less-eager browser vendors to improve the performance too. And so the cycle continues... This is actually exactly how WebAssembly came about in the first place. Asm.js provided a solution that worked on all browsers by brutally and inefficiently repurposing existing technology, but that could be heavily optimized by enlightened browsers. One browser vendor gained a temporary advantage by doing this, and thus forced everyone else's hands. A binary format was just the next step.

I suspect that this dynamic is a general phenomenon that causes technology to naturally trend toward standardization and therefore openness.
1) No[0]

2) Usually money laundering means the money was obtained illegitimately. That money had to come from SOMEWHERE, and someone was probably harmed in the taking of it.

[0]: https://en.wikipedia.org/wiki/Victimless_crime
I think if you follow the thread you'll see that I was responding to ilyanep's derisive comment about NYC as a whole being somehow unworthy of improvement.

Yes, the article refers to something that affects a relatively small number of New Yorkers.
On my first job we had to calculate a lot of MD5's for integrity checks after some downloads (it was completely useless, but part of the protocol). They used the so called "fastest C implementad MD5 program for windows". I outperformed it by 20% with a Python script that used hashlib.md5() and read the file in 1 MiB chunks. Turns out the C program was reading in small (can't remember if it was 1, 2 or 4) KiB chunks, apparently an artifact from older times, while Python handled the disk read a lot better. I was hailed as a hero by my coworkers for speeding up the checks with the "slow" programming language.

TL;DR: things get faster if you know the machine you're working on and how to use it best, regardless of the programming language.
> Nor should we think that extra structure for complex sounds are needed for a language or comprehensibility

A language which evolved from an earlier language, e.g. Italian, or is based on another language, e.g. Silbo Gomero, doesn't need complex sounds to get started, and often replaces "words" in the source language with rules, i.e. replaces lexical and phonological complexity with inflectional and grammatical complexity. But perhaps the very first language to ever be invented will rely on many different sounds and on many different words made from those sounds, but have a simple grammar. A recent study showed the likely dispersal of language from an initial point somewhere in Africa by counting the phonemic diversity, i.e. number of different speech sounds, in various languages around the world. [1] Perhaps the very first language had over a hundred different sounds to compensate for lack of grammar rules.

Perhaps a chin is needed to speak that very first language. Perhaps it had far more clicks than Khoisan, as well as the usual array of consonants, vowels, and tones. Maybe a chin helps with many of the clicking-like sounds.

[1] http://archive.cosmosmagazine.com/news/human-language-spread...
It's free - AWS free tier - and if it weren't it'd cost you less than $0.10/year for the couple hours of AWS nano instances you'd need.
Don't worry, this whole saga sounds like it won't make much money at all.
I think op meant the Federal Reserve, who are not involved in the War on Drugs.
He needs one, and you shouldn't get downvoted for saying this.

Systemd has brought lots of good things to Linux, but tons of bloat and insanity too. I'm quite scared because the next thing they seem to be tackling is one of the core things that makes Linux so nice, package management [1].

They intend to container-ize everything. While that might be in principle good (NixOS got it right), their solution is likely to end up being a mess: no control over container contents. Imagine a critical security bug on e.g. OpenSSL. Good luck patching all your dozens of unmanaged containers running different OpenSSL library instances.

[1] http://0pointer.net/blog/revisiting-how-we-put-together-linu...
Is there a big "I don't want a hill in my backyard" movement?
I'm picturing each individual "feature patch" being defined as a file containing a set of independent per-subsystem code-migrations, the way that database-migrations are files containing sets of independent per-table/view migrations. In order to learn about one subsystem, you could probably get an IDE (I'm picturing something LightTable-like here) to "pull out" all the relevant migrations that went into that particular subsystem, and just read them in order†. Each one would be presented with a bit of surrounding context for the feature-patch that introduced it, the way regular commits are presented with surrounding context from the file they affect.

So, rather than staring at a function's git-blame trace together with commit history to try to deduce a reason for each of the (likely uncommented) lines in it to exist, you would instead just see that the function started simple, and then there was a feature-patch for feature Foo that added lines 1, 5, and 7 to the function, which all reference a global variable $Foo that was also defined elsewhere in the same feature-patch. Etc.

One of the big problems with "only having the diffs" is being unable to know what they add up to: usually, the only way to tell what "flat schema" a set of DB migrations add up to is to run them against a real RDBMS and then dump the resultant schema. But again, with a LightTable-like editor, I could easily imagine each feature-patch being presented together with the "generated context" of what the resultant function looks like at that point in the code's history—or what it looks like now—with that feature-patch in play. You could tweak the feature-patch, save, and the code in the other pane would auto-update.

---

† One interesting thing is that there would definitely be times where a particular subsystem got a feature added, and then removed when it became unnecessary or was obviated by another feature. The feature might persist in other places (so you wouldn't git-rm the entire feature-patch that introduced the feature) but rather than seeing a complete feature history for some subsystem Foo (+A, +B, -A), it would be useful to be able to get an "abridged" summary of Foo that just introduces feature B and pretends feature A never happened.

Both views would have their purpose; the abridged view would be more useful for first learning the subsystem, while the unabridged view would be more useful for understanding the codebase as a whole, since you could see why, for example, there are two logging systems in play—it would be clear in unabridged view that one is in the process of replacing the other, but there are some subsystems where the newer one hasn't yet been introduced.
For academic research, I find https://www.zotero.org/ useful. AGPLv3 license, good integration with web browsers, and good sync. It has tagging and custom notes although I prefer using folders and a separate note taking app.
I disagree. While I agree that web UI programming can undeniably be described as complex:

a) JS, HTML and CSS have been designed to build more than "documents" for over 10 years.

b) Contrary to the idea that these technologies lead to bad API, I see many high impact graphics toolkits moving to a CSS / HTML driven model even when the teams working on these toolkits are not majority web developers. Quick examples: GTK3 and Source 2.

c) There are many Javascript frameworks that do not require deep knowledge of all three of these technologies to produce something. The vast majority of Javascript UI toolkits, for example jQuery UI aim to remove the need for in-depth knowledge of HTML and CSS to produce user interfaces.

d) While I agree with you that there is no one true way to tie together these technologies, I think there are solid abstractions that tie HTML, Javascript and CSS together. I've been very excited about how terse and powerful d3 is for composing any kind of HTML/JS/CSS model.
Crimes require violation of criminal law, which may or may not involve a victim (the legally offended party in a crime isn't the victim, if any, but the State; that's a pretty central distinction between crimes and torts.)
Or, you know, have access to one of the world's premiere research institution's data in real-time. The amount of NDA'd traffic alone across UC's network is enormously valuable. How many private companies made of valuable, transmittable IP have have endpoints within that network?
Need to be licensed as an MSB is based on where your customers are located, not your business.
You make it sound like there aren't any humans involved in maintaining such huge platforms and eco-systems as AWS and Azure.
I don't have anything to offer (sorry!), but I am curious on this too. It's something I'd like to try out one day.
You mean an extractor fan?
1Gbps for the crawler totally explains it: I can see that doing 600 URL/sec. xD

I didn't think of CloudFlare being able to see the traffic... and wow, I never even processed that aspect of their service. But of course...

How good is Google's "[ ] I'm not a robot" checkbox thingy at weeding out bots? And perhaps you could use multiple captcha systems...? (Or are actual people tasked to do signups?!)

I shudder to think of such an idea, but linking API keys to <popular login-with/connect-with-this-site API> may be an alternative. (One thing that comes to mind is that, if someone authenticates using Reddit - which they can do without releasing any account info - is that you could check their (public, but unfakeable) karma counts and use that as a measure of confidence, in addition to the standard account age metric used everywhere.)

The new design is nice :D

And if it's been a year (!), another Show HN sometime would certainly be fine.
Granted. But a unit expression is only useful for its side effect so I guess I put that in the gray area between paradigms, not really in the spirit of only evaluating expressions. Which brings us back the point of my comment: It's almost certainly a bad idea.
The two have often been compared, but BlitzMax is lighter on resources, plus i think DarkBasic has a camera system for 2D rendering while BlitzMax doesn't.
Bingo. You're only a call to SetFirmwareEnvironmentVariable away from having your Windows system hosed.
There's Clojure too, if you are into that. Check this out http://codahale.com/a-small-nice-thing/
> The problem is that the people who design JS frameworks insist that you have to be able to use JS, HTML, CSS. This leads to bad API, you reuse something that was designed for documents for applications, and no one really knows how to map these different things properly.

ExtJS. An old, mature JS framework designed for desktop-style apps on the browser. ExtJS code doesn't look like web code at all - no mentions of DOM and styling and stuff like that. All about widgets and data-binding, like making a desktop app. It's not perfect - being almost as old as JQuery, it has some flaws that would have been avoided in newer frameworks. But it's there and I use it professionally.

The problem, of course, is "why does our webapp look like a desktop application but with non-native widgets?"

Now everybody expects the web to be all designer-y. Even for a line-of-business app. It's on the web, it should look webby.
Better GitHub search tool. “Tag” repos and filter/sort
>Your average BlitzBasic "Hello World" would usually take up 50% of the CPU

On the Amiga?