What's sort of peculiar is - as far as I've seen/read - he's never been penitent about his past unethical behavior. No: "Yeah, I used to be a dick. I regret leading my company that way" or anything like that.
I rather legal opinions not fall back on founder-worship for their legal basis...
The founders explicitly didn't include any rights in the constitution. The Bill of Rights was begrudgingly added later as a compromise after the constitution was approved by the states.
Furthermore, the right to privacy is really not on the same level as the other rights (where things are more black and white) and the 14th amendment was passed in the 1860s - well after any "founders"
"When you get back to the "real world" you'll never see it the same again :)"
I've been thinking about taking 9 months off (specifically traveling China, and learning Mandarin).
I'm worried that with all that taste of freedom I'll have an even harder time coming back and sitting in an office 8hrs/day (some weeks it's already like pulling teeth)
Then don't. It's really pretty easy to get in to contract programming (making assumptions here). Especially if you default to long-term contracts. It's basically like a job but you get to pick how many hours you put in.
I've heard that the whole quantum tunneling stuff is in practical terms bullshit. While it's a real effect (and physicists looove to talk about it), it's virtually irrelevant b/c the overwhelming issues is parasitic capacitances. When you have a 3Ghz clocks, everything acts like a capacitor and you have current leaking all over the place (the smaller the circuit the closer all the elements are).
So transistors in modern processors don't end up switching consistently. There is all sorts of error correction to compensate for that, but it only goes so far.
The gate leakage current was a serious concern until the High-K gate dielectric was found. It increased the gate dielectric thickness so tunneling current is reduced significantly (exponentially). Nowadays the main problems are subthreshold leakage and dynamic power. Here's a good article about it:
> the main problems are subthreshold leakage and dynamic power.
This is exactly correct. Even at 28nm, many SoCs are intentionally using less than the max manufacturable transistor density, due to dynamic power/thermal constraints.
SRAM is scaling poorly too. It makes up 50-60% of many SoC designs yet at 1500MHz+ its density (Mb/mm^2) looks likely to increase just 1.1X between 28nm and 16nm.
Desktop CPUs are not going to get 32MB on-die caches any time soon. At least not without eDRAM.
MATLAB will recognize if you've got FFTW or ATLAS or other highly tuned numerical libraries installed. And MATLAB will then use them whenever possible.
If Intel does a good enough job of providing a collection of compute kernels and the surrounding CPU libraries to make using them roughly as "easy" as CUDA then a lot of people will pick that up.
I don't have any hard numbers but I would suspect that there are a great many more people who use MATLAB on a CPU than those who do MATLAB->HDL. So what I'm speculating about is that Intel might support those folks who use MATLAB on a CPU for more general purpose things.
I think the general priority has been to improve single thread performance and for good reasons.
While there are plenty of problems that are parallelizable, a great majority of problems are sequential. Even if you think of say on the OS level - of running every process on a separate CPU/core/whatever - the single thread performance still comes out being the most important factor
After a first reading I felt that it really resonated.
However, if you think of people that do persue what THEY want from life, they are often quite miserable too. Asking yourself "what would you do if money wasn't a concern and you had all the time in the world" ends up not being particularly meaningful. People born into wealthy families try to figure out what THEY want out of life, and end they are just as depressed and full of self-doubt. Sure you can spend a year surfing in Hawaii, or painting, or gardening, but they end up feeling like ephemeral distractions (unless you go all out and turn into an adrenalin junky - though I don't know honestly how happy they are). Lasting motivation comes from your interactions with the world - and often "doing things that OTHER people wanted" is (if you're honest with yourself) to a degree "what YOU wanted out of life" .
It's because the slip opinion (the one posted on the court's website) is not canonical. The canonical version is what's published in the U.S. Reports.
The Supreme Court has a whole protocol for this: http://www.supremecourt.gov/opinions/slipopinions.aspx ("Caution: These electronic opinions may contain computer-generated errors or other deviations from the official printed slip opinion pamphlets. Moreover, a slip opinion is replaced within a few months by a paginated version of the case in the preliminary print, and--one year after the issuance of that print--by the final version of the case in a U. S. Reports bound volume. In case of discrepancies between the print and electronic versions of a slip opinion, the print version controls. In case of discrepancies between the slip opinion and any later official version of the opinion, the later version controls.")
The GigaOm article is garbage: "Supreme Court opinions are the law of the land, and so it’s a problem when the Justices change the words of the decisions without telling anyone." They're trying to generate page-views by making it sound like the Justices are going back and changing the official record, and are being thwarted by a coder who swoops in to save the day.
In reality, what you have is a tool to see what changes between the "release candidate" and the "Gold Master." Still interesting, even without the manufactured drama.
It's much more important than that. Yes, the protocol says it's only for errors/deviations. In practice, the changes can be more substantial.
The vast amount of legal, scholarly and media attention to an opinion happens on release day. When words change after release day, the public deserves to be immediately clued in to that -- even if many/most of them end up being typographical.
Quite its "the words on the paper" I once spent an hour discussing with colleagues on a business committee (plus getting expert opinions from two officials) as to the exact meaning of "the" in a motion - to rule a motion in or out.
If the supreme court need to make changes it should be shown as a omnibus document with the changes indicated and I trust the justices will look at the revised motions and vote on all! the amended judgements.
If they don't they should be impeached for malfeasance in public office and replaced.
There's a non-binding vote in conference, and at that point the majority chooses a justice to write the draft opinion. The justice who write the opinion circulates it among the justices for recommended edits. That basically becomes the slip opinion.
Other justices can write concurring or dissenting opinions as they wish. The justices and change their mind at any point until their judgement is officially handed down. So (at least in my understanding, someone please educate me if I'm wrong) there is no vote on the majority opinion itself, but rather on the case and the general points of law.
Therefore there's no reason the other justices would feel the need to vote on revisions.
But as stated, it's well-known and well-documented that these opinions aren't finalized and what we see at first is just a draft. Frankly there's no one to blame but ourselves and the media for thinking otherwise. I don't really have any problem with this behavior - as the NYT noted the changes are noted, just not as publicly as they should be.
And, in general, the Justices don't even write the opinions. According to the book 'The Brethren' by Bob Woodward, the bulk of the text of opinions are often written by clerks and reviewed by their supervising Justice.
Isn't a like a judge making an initial ruling and then the next week saying oops that death penalty thingy I have changed my mind?
And if you are making revision you need to publish the actual changes not just slip out a new version ie para A3 delete last sentence and replace with "foo bar".
Dont they cover that at "judging school" to quote the E L wisty aka the late Peter Cook
1. The rulings of the case don't change, the explanatory comments and reasoning gets further edited after the ruling - any changes there would affect decisions in future cases, but not for this one.
2. After they're finally published in U.S. Reports, any changes are published as proper errata. However, the 'post on the website' is of a draft that's after the ruling but much, much before publication.
All this article is about tracking the changes that get made before the U.S. reports version is published, and the 'slip' version is essentially described as "this is a pre-release draft, read if you want but the following publications may be different and that will be binding, not this one". If you read a draft of a novel, do you expect the released version to include an errata of things that were changed from that draft?
I would expect the highest judicial court in the land to ONLY publish final documents any drafts should be between the justices and the clerks. Why do I say this to stop the risk of media jumping to conclusions and getting the wrong end of the stick and thus making the supreme court look like amateurs.
Certainly when I have been involved in formal parliamentary style work we would never publish a draft.
Well that's a lot more reasonable - but it seems like they should just hold off on publishing the thing till they finish editing it. The system seems a bit sloppy
A Supreme Court opinion has several functions: 1) it resolves a real live dispute between two parties; 2) it gives guidance to the other federal courts; 3) it serves as a statement of the law to the public.
For (1), you want to publish immediately, because the parties have already waited a long time to get the dispute resolved. For (2), you want to publish quickly, because the federal Courts of Appeal need to implement the new guidance in other cases, and may be holding cases that pose the same question pending the Supreme Court's resolution. For (3), you want to have enough time to polish something, because it will be referenced for decades to come.
The system of publishing a bench opinion, a slip opinion, and a final published opinion reflects these conflicting needs.
Approximately nobody in the US would rather wait for the final binding version of the opinion, for avoidance of uncertainty, than read about the bench opinion on CNN. The very few people who care about this issue already know they need to watch for the preliminary and bound opinions.
The SCOTUS website itself is excruciatingly clear about these points:
The opinions published immediately after the announcement of a decision are marked as draft and subject to change. They then undergo editing, until the official final version gets published in the U.S. Reports. (The NYT article describes this).
I would be floored, completely bewildered, and stupefied beyond belief if any Congress other than the 113th thought they had the ability to legislate what the Supreme Court can write in its decisions.
Having said that, I expect such stupidity to be debated in committee by the end of next week.
You might want to read up on past Congresses since the 113th is actually pretty tame compared to quite a few of the others. Speaker O'Neil could get quite vicious and he wasn't even the most powerful Speaker.
> I would be floored, completely bewildered, and stupefied beyond belief if any Congress other than the 113th thought they had the ability to legislate what the Supreme Court can write in its decisions.
There's a difference between legislating what the Supreme Court can write in their decisions and legislating the manner in which the Supreme Court must publicize its decisions and changes to them.
And the issue, to be clear, here is the latter, not the former.
> Your argument might be stronger if it suggested a source of authority for Congress to pass such a law.
The most obvious The elastic clause of Article I, Section 8 (insofar as las specifying the manner of publication of Supreme Court decisions are "necessary and proper" for carrying into execution the judicial power specified in Art. III), and, additionally (for most decisions) the appellate jurisdiction clause of Article III, Section 2 (which limits the court in such cases to operate "under such regulations as Congress shall make".)
Anyway, I never argued Congress could make such a law anyway, I argued that they hadn't (thus the current behavior wasn't illegal), and that there was a substantial difference between regulating what the Court can write in a decision (substance) -- which someone suggested would be ridiculous -- and regulating how the Court must publicize decisions (process). I didn't say that either restriction would necessary be within the power of Congress, just that they were substantially different things.
For the reasons cited earlier in this post, I suspect that the kind of regulations that would be relevant to this discussion on process would be within Congress power, but that's somewhat beside the point. I mean, if Congress can't make a law regulating the process, that would be an even stronger form of the "Congress hasn't made a law" reason for it not being illegal.
Well... Congress has passed laws impacting venue decisions, and Congress can change the composition of the courts, for instance by adding new judgeships. Congress also creates special administrative courts like FISA.
It would have been clearer for me to say that judicial branch does its own administration, which includes rules on everything from procedure to publication of court decisions.
" ...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.' But the plans were on display...' o n display? I eventually had to go down to the cellar to find them.' `That's the display department.' `With a torch.' `Ah, well the lights had probably gone.' `So had the stairs.' `But look you found the notice didn't you?' `Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".'
The industry doesn't really make that much money. Estimates for this past year were in the $1-2 billion range. That's not big for the finance sector, or any industry. That being said, it doesn't take that many people to run a shop, so individuals may be paid a lot.
They don't make tons of money. I think Michael Lewis quotes a annual revenue of 16 billions for all the HFT companies put together. That's less then half of goldman sachs' revenue alone.
I'd be very hesitant with "commit often". Each commit should represent a finished bit of a bigger feature.. Each commit should compile (...generally. With exceptions). Commits that fix spelling, or change some spacing issues end up cluttering the history and making it hard to see what's being actually done. When someone looks over your code they should see things like:
commit1: he/she added some methods
commit2: refactored some code
commit3: he/she plugged in the methods created into the refactored code
etc.
The branch as a whole should be a finished feature. Keep the features small-ish. Try not to have a branch that living on it's own for a long time. You can merge the master branch into it, however you'll slowly be out of sync with your team b/c they don't really know what you're up to.
The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.
The workaround is to make a new branch and cherry pick changes - but it's a huge PITA and easy to mess up
Aside:
Does anyone know what diff tool is best for working in C++? The diffs I commit (using kdiff) can sometimes be mind-boggling hideous b/c the diff program parsed things in some strange way.
The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.
Thanks for the pointer. In truth, I use a GUI (gitExtentions). I like it a lot more than the command line. Hopefully this is implemented somewhere. I'll look into it!
Maybe I'm not well read enough about it though