skysight-inc/HackerNews huggingface dataset:
Perhaps the title was a tad flippant. You can use Django in a microservice architecture although if your services are small enough I would hazard to say that Django would be overkill for most implementations as it is not what it is designed for.

Saying that if it increases development speed and makes sense in the scenario then I wouldn't shy away from it.
I also have a friend I want to start a startup with. But like you're friend, he has the same misconceptions about businesses most people have. But I like him & I think we would make a great team. So my plan is to watch http://startupclass.samaltman.com/ with him before we start anything.
> If we set _foo to 0 and have two threads that both execute incl (_foo) 10000 times each, incrementing the same location with a single instruction 20000 times, is guaranteed not to exceed 20000, but it could (theoretically) be as low as 2.

Can someone explain the scenario where this test would result in _foo = 2? The lowest theoretical value I can understand is foo_ = 10000 (all 10000 incls from thread 1 are executed between one pair of load and store in thread 2 and hence lost).
>FP as I understand it doesn't much oppose imperative or even most of OO

I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see.

>* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that

That's also true, but it's not an argument against the seed of usefulness of the 10%. We have kitchen sinks because people pick and choose features at will.

>* FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely.

Same here, and everyone should practice this when they look at any function, or object method, trying to make it as atomic as possible.

> This may end up being some kind of full-scale OO

I don't think it's any more useful shoehorning a program into "everything objects" more than "everything is functions".

My point was to say that the core goal of OOP is a great one, it simply codifies something that people have done in C when they put structs and procedures in the same header file. Let's not throw the baby out with the bath water.
In my experience with microservices, the vast majority of bugs were in services not talking to each other properly, or in some variation of that interface. There are some security complications that means services aren't very free to talk to each other (which introduces complexity), but, overall, I think I prefer the monolithic model. Our Django app isn't too hard to set up, requirements.txt contains everything and the rest is in an Ansible playbook.
>If we set _foo to 0 and have two threads that both execute incl (_foo) 10000 times each, incrementing the same location with a single instruction 20000 times, is guaranteed not to exceed 20000, but it could (theoretically) be as low as 2.

Initially it seemed to me the theoretical minimum should be 10000 (as the practical minimum seems to be). But it does indeed seem possible to get 2:

1) Both threads load 0

2) Thread 1 increments 9999 times and stores

3) Thread 2 increments and stores 1

5) Both threads load 1

5) Thread 2 increments 9999 times and stores

6) Thread 1 increments and stores 2

Is there anything in the x86 coherency setup that would disallow this and make 10000 the actual minimum?
What do you think and WHY is the best suited tool for true RestFul APIs in Ruby
You can't expect everyone to master everything. It's like ranting about how the whole classroom haven't got A+.

It's pointless ultimately.

The real question is how can we improve a protocol so it's better used by most people. Hence why it's evolving. Nothing should be set in stone forever and then expect everyone to comply to it or die.
There is nothing that prevents Uber/Lyft from being a race to the bottom re driver revenue. I think that should've been obvious to anyone looking at the model from the beginning.

One of the first questions is to ask about a business is whether there are any barriers to competition. In the case of Uber or Lyft, they have network effects but the drivers themselves have no barrier.

Years ago some Subway franchisees sued Subway because they were selling franchises right across the street from existing franchises. Same issue. There will always be more drivers, Uber/Lyft control the rate, so no limit to how far drivers can be squeezed.
Yeah, but that's harder when everyone knows Erlang, and one guy goes off and writes something with, say, Django for fun.
Thanks for the suggestion, that is exactly what I did.
Yes, I should have said “unbounded length field”. But, with respect to the discussion, a 32 or 64-bit integer is only bounded in the academic sense.

Also, here is a video that works a bit better as an introduction to LANGSEC: https://www.youtube.com/watch?v=3kEfedtQVOY (around 19:00 is especially entertaining)
I think there is something to notice about having a hard fixed timeline for everyone. See from the bug:

https://code.google.com/p/google-security-research/issues/de...

> Microsoft confirmed that they are on target to provide fixes for these issues
in February 2015. They asked if this would cause a problem with the 90 day
deadline.

< Microsoft were informed that the 90 day deadline is fixed for all vendors and
bug classes and so cannot be extended. Further they were informed that the 90 day
deadline for this issue expires on the 11th Jan 2015.

> Microsoft confirmed that they anticipate to provide fixes for these issues in
January 2015.

So basically Microsoft asked for an extra month, and they said no, which forced them to move quicker, and fix it a month earlier. Without picking any side of the debate, you can still see what effect the non-negotiation of timeline has on getting patches out as soon as possible.
Here's an idea. Knowing Redmond's schedule, could they have notified them but set the disclosure date 2 days ahead? That seems like professional courtesy.
https://github.com/darkitecht/InsideReCaptcha lulz, the Streissand effect is a real killer
If you define a limit for disclosure, and then not stick to it, why to define a limit in the first place? 90 days is more than enough - if MS has a lot of internal overhead, you should probably complain to them, not to google.
Except that they're not; rather, they're ARNs. URNs must begun with 'urn:'. It doesn't make a lot of sense that they're not URNs, but…they're not.
Lower gas prices in most UberX cars is barely going to matter.

They really do need to replace casual car use/ownership, but I think rather than continually drop effective wages for their drivers, they need to focus on how good a deal it already is. (compare to mileage on your car, fuel, parking time, parking cost, Parking location)
'Worse Is Better' 25 Years Later – Have We Gotten Lazy?
> before we know it, Ubers will be rude, yapping on their phone in unknown languages, and the cars will have torn upholstery and reek of incense

I understand that you mean to say that you expect the quality of Uber rides to drop, but can you do so in a way that doesn't draw upon negative stereotypes of other ethnicities?
Everyone is saying that Google should have waited for Microsoft's patch day, but why should Google bend their standard procedure to fit Microsoft? If it really meant that much to Microsoft, they could have released a patch earlier.

They knew they had 90 days and decided to ignore it.
Or you could ask: do two more days of the bug being secretly exploited in the wild matter?
Yes you're right it is slightly overstated. We still use our Django monolith to compensate for not re-writing every single part of our codebase.

However overtime I would imagine we would move away from Django as with small enough services it would be overkill as a solution.

Saying that, if it makes sense at the time then why not. With this architecture you have the flexibility to do that.
In a 30 MPG car, the drop in gas from $3 to $2 is a 3 cent difference per mile. UberX charges from $1.50 to $2 or so per mile.

So gas price seems like a red herring to me.
The types of Uber cars available varies depending on the city. If available, choose BLACK CAR if you want a better car. In NYC we have uberT, uberX and BLACK CAR (and sometimes RUSH, for deliveries). Inside those major categories are subs; uberX has uberX, uberXL, CAR SEAT. BLACK CAR has BLACK CAR and SUV.
The point is that a part manufacture has to go through the right channel (ie, get certified, inspected regularly) to have the 'right' to make parts.

You wouldn't want parts of questionable quality being put on an airplane, some goes for your car too.

Even certified after market parts have their issues too and seem to get worse (in quality) every year.
Well said.

I work with Palantir guys and helping them with data sources at a large banking firm.

Everything is custom, needs to be customized and then it needs to be changed every month.

The magic bullet here is hard work and smart people.
Alternatively, and without your unsubstantiated knocking of Microsoft, perhaps they were needing to conduct serious regression testing. This isn't the "unit tests pass, whack it into production" leagues after all.

Plus there's also the small matter of Christmas, and for many countries, significant developer unavailability falling into that period.

What's more likely, Microsoft can produce, test and deploy a patch in a few days, but chose not to until they had to. Or that they did get a patch ready and tested, but not in time for the patch Tuesday the previous month (so actually got it done in ~62 days) but it didn't warrant an out of band release?
I find the claim "if your services are small enough ... Django is an overkill" baffling. When you're writing a simple program / command-line tool, do you use a minimalistic programming language or do you just stick to your Python / C++ / whatever? If you have Django expertise, how does it make sense not to just use it, and worry about "an overkill" instead? Overkill in what sense? In the extra 500KB of memory Django uses? In the extra few MBs of disk space? I just don't get it.
Having been both a founder and an early employee, I wholeheartedly agree with this. Early employees really do wind up working nearly as hard as founders and the payoff is extremely disproportionate. The most likely scenario by far is failure, so your equity will be worth nothing. Your next-best hope is a moderately-successful exit, where the investors get their money back, the founders get enough to have made the endeavor worth their time and the early employees walk away with a few thousand. Hardly a year-end bonus at a bigger company (which you can expect _not_ to get at a startup). The Facebooks and Twitters of the world, where many/most early employees become millionaires are few and far enough in between to be essentially lottery tickets.

However, if you are totally fresh and want to gain some experience, it can be worth your time. The market for developers right now is such that you may not need to take such a pay cut vs a bigger company. This is the real variable. What are you giving up. And while you may work about as hard as a founder, you aren't as likely to wind up ruining your credit and destroying relationships with family and friends due to the incredible stress.

So it may be worth it for the experience. Just don't get sold on being an early employee as a path to riches via your equity. That path is vanishingly rare.
Gah, it's perfectly possible to use Django without DRF for simple REST services. If you need simple things, it's not a big deal.
Zero tolerance policies are never a good idea, there's always some exception that seems far fetched until it actually happens that proves this.
Here's why you don't want Unicode identifiers:

http://www.globalnerdy.com/wordpress/wp-content/uploads/2014...

(And yes, that compiles and runs on Swift using the XCode 6 beta.)
You're just citing the press release (or a blog post, or whatever). How does that respond to the original question?

The issue mentioned in the article [https://code.google.com/p/google-security-research/issues/de...] says that:

> Microsoft confirmed that they are on target to provide fixes for these issues in February 2015. They asked if this would cause a problem with the 90 day deadline.

< Microsoft were informed that the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended. Further they were informed that the 90 day deadline for this issue expires on the 11th Jan 2015.

So (a) Microsoft is unable to comprehend a simple 90-day policy or (b) do basic math.
Microsoft was actually asking for 92 days to fix the bug, not 2 days...
The green line is the only one that Moore's law is about. Power consumption plateauing is a good thing, clock speed was never going to be the primary driver of performance increases long-term, and instruction-level parellelism (green line) is not a measure of performance-per-clock-cycle.
If you start making exceptions, everyone will want one.
I can see a case for microservices as a way to break down complexity. But introducing languages willy-nilly could have maintenance nightmares along the road.
Indeed. It is amazing how the cars that sell and make money are not the fuel efficient ones...

I only know the gas mileage of that car because my step dad that owned it would write down the current mileage and the amount of gallons fueled and then once there were a hundred entries like that on a piece of paper, he would make my calculate the mileage for 'extra practice' homework -__-
It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.
The authors point still holds if writes might not appear in program order on other CPU sockets, not just other cores within the same socket.

Do you have a reference for the strong memory ordering on x86? I'd like to read more about it.
Show HN: Build Your Own Bespoke Docker Image from Source
>yapping on their phone in unknown languages

I'm surprised more cities don't ban cell phone use by the drivers. It's the single thing I hate most about NYC cabs.
As opposed to 2 days of the bug being openly exploited?
Your bandwidth costs are going to be stupidly large and ad revenue right now is in the toilet. You are going to wonder how so many people know about AdBlock and unless you have a stranglehold on your content your ad fill is not going to be easy.

> Is there a video hosting service that provides a sort of pre-built content management system for videos that allows our user base to upload their content, to tag it/categorise it and share revenue?

Yes, it's called YouTube/Vimeo/DailyMotion. Do you really want to try and compete there?
It's not about bending to another company's internal policy. It's about having etiquette for the company patching the vulnerability that extends beyond the basic rules; especially when it could harm users. What Google did certainly stayed within normal policy, but that doesn't make it good form.
This is also a pretty good set of guidelines by Google to follow: http://static.googleusercontent.com/media/www.google.com/en/...
> Does it really matter if it's 90 or 92 day disclosure?

Yes. Google designed Project Zero to "pressure firms into dealing with security problems more quickly." A firm policy with unambiguous enforcement has its advantages. Muddying the 90-day deadline with questions about when (and for whom) to make exceptions weakens it. For example, in the future, I expect Microsoft will not wait the extra two days in the event of a security disclosure from Google.

One may disagree with the 90-day policy to begin with. I, for one, think it should have had an exception process built in. But while these are Google policies, not laws, I respect them for adhering to published protocol. Even when it was difficult.
As another comment points out, unlike Google updates, Microsoft's occur on a particular day of every month. This allows end user IT departments to coordinate the updates as part of a predictable change management policy.

In this case, the bug was reported on 13 Oct, 15 working days before the first Tuesday of November. Assuming Microsoft couldn't fix and test a change to a core service running on millions of desktops in that time, their only remaining opportunity within the disclosure window was the patch day in December - allowing them only 50 calendar days to deal with the bug.

What's worse is that the bug isn't even all that severe. Effectively Google were trying to strong-arm Microsoft into releasing an out of band patch for a minor issue, which would have knock-on effects for thousands of IT departments. A completely dick move, and thankfully one that's being given recognition here.

Shit like this is why I have a hard time dealing with the infosec community in general – a strange mix of conformance to pointless minutia, a deeply ingrained sense of self-importance (only worsening over time with PR crap like APT), and a fatal attraction with some of the most puerile elements of society. The result is a unique melting pot of genius and dumb that I regularly can't stomach.
Polyminos: A Way to Teach the Mathematical Concept of Implication [pdf]
A Call for Better Vulnerability Response
MS is closed source? People Bitch.

MS moves to open source parts? People Bitch.

Can't win...
So you're saying Google should make an exception for Microsoft? Its bestest friend ever? What about Facebook? Apple? Oracle? Why not just stop throw the 90 day rule out the window at that point, to fit everyone's schedules?

It seems to me Microsoft is like that student who has 3 months to do a project, but waits until the last 2 days, and then asks the professor to give him some more time. It was Microsoft's responsibility to patch the bug at the last Patch Tuesday.
So this site, among other things:

* Until recently, used stateful numbers for all links
* Uses the same location for different resources (e.g. https://news.ycombinator.com/item)
* Serves the same resources at multiple different locations, rather than redirecting you to a canonical location.
* Does posting, editing and deleting via POST, not CREATE/PATCH/DELETE
* Does approximately no content negotiation
* Does not support non-browser clients at all, which, well I suppose you could make a perverse argument that that is HATEOAS.

In short, it behaves not at all like the system described in the REST paper.
Flask is so minimal. Curious what were the disadvantages that weighed against chosing Flask.
Not sure what you're trying to do. But we've found the best part of DRF is that it creates a great structure to build off of and gets everyone writing APIs the same way.

We haven't separated many of our services out but we actually have extended a lot on top of DRF. We created a way to do internal requests, so now instead of passing querysets to HTML views we actually do an internal API call. In the future, that code can be moved into it's own service.

Abstracting things out like this allow us to plan for microservices in the future while not having to deal with tons of different codebases and deploy strategies right now.

In the past year as we've scaled from 3 to 20 developers, I would say that DRF is the single-most crucial element that helped us scale the team without any massive issues.
As a business if you want to encourage your developers to improve by exposing them to more different types of languages and technologies then I am all for it. You can fund a weekly Haskell class. You can implement a 20% time initiative and let developers work on prototypes using whatever tech they want. For your production systems, however, you need to have some boundaries to serve the business even if you are a tech company run by engineers.
THE WEB WILL KILL APPS
A few observations:

Google headcount: ~49k
MS headcount: ~130k

There is going to be a huge difference in speed based on size alone, but MS also has a much greater commitment to regression testing than Google ever has.

Google has embraced an engineering culture where the security team can contribute fixes directly to their own projects. I imagine this creates an unreasonable prejudice culture about how easy it is to implement fixes without concern for regression issues. You can see examples of this in recent e.o.y will not fix bug closures in AOSP. Those savants are going to set the usability vs security debate back a decade by by marking all http connections as insecure.

Finally, don't forget that Eric Schmidt agreed to a recruiting cease fire. For. All of their pride and arrogance, those Google security engineers are never going to escape the fact that they have compromised their own potential maximum value so they can sneer at other companies cultures.

Toxic and stupid.
definitely a p5 :-)
How about Google sponsors Microsoft human and financial support to fix the bugs if they really care about that?
Github Student Developer Pack includes Visual Studio and Dreamspark
Nice, does one thing but does it well. The only thing that puts me off a bit is the grey background, as I associate the pomodoro brand with red - I like the way the pomodoro icon changes color to reflect the state though, so I can see why you went with a neutral color
New York banned cell phones while driving at least 14 years ago.

EDIT: Next time perhaps report your cabbie?
Look, I'm been really happy with a lot of the stuff Microsoft has been doing recently, particularly in open source. But this is ridiculous. They had plenty of notice that Microsoft's standard 90-day (90 day!) policy applied, and that no exceptions were going to be made.

I applaud Google for not bending on their 90-day deadline (assuming they do hold all companies to that, and it appears they do). Maybe this incident will help encourage some companies that might otherwise be lax when confronted with a bug to hurry up. There's no telling who else knew about this bug and was actively exploiting it (probably lots of people).
This throws an error:

typeof x; // throws an error
let x = 1;

This doesn't:

typeof x; // returns "undefined"
var x = 1;

While using variables before declaring them is bad practice, I think it's fair to argue that this behaviour is inconsistent.
I agree with this completely. Even if Google didn't know about patch days they should have allowed them two more days to release the patch since they asked for it. I would even say they could have given them another week window if they needed it. Releasing an exploit into the wild when you know a patch is coming is a really awe-full thing to do. If the tables were turned I wonder what Microsoft would have done here.
It's the opposite of bureaucracy. Strict simple rule cuts the bureaucracy off.

If you don't have it, then you have a lot of time wasted on communication, handling special exceptions, making decisions if you should bend it or not and so on.
(c) is perfectly capable of both, and since we're mature and reasonable adults here, we'll leave open the possibility of extenuating factors
Or just RTFM (if that's relevant for your model)?

Pre-selecting a speed:

You can pre-select a desired speed while the vehicle is stationary.

– Switch on the ignition.

– Pull the lever to position 1 ⇒ page 125, fig. 134.

– Push the lever up towards or down towards in order to increase or reduce the cruising speed setting.

– Release the lever to store the cruising speed setting displayed.

This function allows you to enter the desired cruise control setting speed ahead of time, for example before joining a motorway. Once you are on the motorway, you can activate the cruise control system by pulling the lever to position.

https://www.gebruikershandleiding.com/Audi-A4-2008/preview-h...
In the section on rdtsc, the author should really mention that there's a new, serializing version called rdtscp, so you should prefer that.
Welcome to the wide and unimpressive world of tech journalism. On the other hand, you get what you pay for.