Most ISPs don't require this -- you can use your own equipment if you wish. Most customers take them up on the rentals, though, either because they don't know any better or because it's easier than buying and maintaining their own equipment.
Most people understand that fine. It's about freedom of speech as a social principle and value, not strictly a matter of law.
It's granted that people are within their rights to throw out speech they dislike and that there's a world of difference between severing a voluntary business relationship and the deployment of state force, but the implications of an anxious, PR-sensitive set of internet infrastructure providers is certainly fair game for discussion.
If we get into the habit of shutting down every site that attracts a spate of negative attention, it still has the aggregate effect of chilling free discourse. If a shooter came onto HN and posted a manifesto here, would it withstand the mainstream media onslaught?
Right, Leventhal mentions that such an eventuality was one in a group of several considerations, but clearly does not think it was the primary factor.
From the paragraph following your quote:
> Finally and perhaps most significantly, personal egos and NIH (not invented here) syndrome certainly played a part. [...] [C]ertain leads and managers preferred to build their own rather adopting external technology—even technology that was best of breed. They pitched their own project, an Apple project, that would bring modern filesystem technologies to Mac OS X.
and
> Licensing FUD was thrown into the mix; even today folks at Apple see the ZFS license as nefarious and toxic in some way whereas the DTrace license works just fine for them. Note that both use the same license with the same grants and same restrictions.
Leventhal's chronology continues to suggest that ZFS on OS X re-emerged even after this licensing argument had been advanced, and that the project was finally killed by Larry Ellison himself, in the interest of keeping his personal friendship with Steve Jobs unaffected by business considerations.
While it is of course possible that Apple is willing to accept any "murkiness" around the license as it pertains to DTrace but not willing to do so as it pertains to ZFS, it just doesn't seem like your original statement that "they had to drop the whole thing because of the murky licensing on ZFS" represents the situation clearly (at least not if we accept the version of events as told by Adam Leventhal; personally, I have no direct knowledge).
Adam Leventhal doesn't seem to put much stock in the licensing theory, considering OS X's inclusion of DTrace, which was released under the same license. His discussion of the saga of ZFS on OS X is here: http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/ . Very interesting stuff.
The problem is not the salaries or the perks that drives the unprofitability, it's simply the investment model. If you're backed by venture capital, you're goal is to get to an exit 500x larger than the investment ($2M round; VCs don't invest unless they think they may make $1B+). That requires people to focus on growth and world-eating more than any respectable-in-the-moment profitability numbers.
Disclaimer: I'm not a lawyer, there are definitely people who can explain this better, and I'm probably using these terms incorrectly.
Yes, mens rea is an important consideration, but it's nuanced. Check the Model Penal Code [0], which identifies four differing types of mens rea, including negligence and recklessness; that is, a "guilty mind" (mens rea), for criminal purposes, does not necessarily require what would be conventionally considered bona fide malice or intent to harm.
What I meant when I said an "enhancement" or "aggravating factor" is that usually you have an objectively asocial actus reus, like theft, and should mens rea come into play, it's generally a defensive thing seeking to exculpate the accused, as in "I didn't know it belonged to someone else" (the affirmative defense), not to deny the act.
But with insider trading and other instances of nuanced malum prohibitum [1], the usual relationship between actus reus and mens rea is inverted. To make the crime, one starts with the mens rea, the bad intent, and must identify (or, if necessary, manufacture) an apparently-normal act to register as the external offensive conduct that harmed society and warrants legal action.
That is a scarier proposition because if your daily business involves technical acts that can be converted into actus reus, there's obviously going to be ample opportunity for people to assign and rationalize their preferred ideas about your thought process there and convince themselves that you're a criminal based on their personal level of dislike or offense. If this gets brought in court, your defense will amount to convincing the jury to believe you instead of the prosecutor, which is a straight-up likability and performance contest.
Whereas, with better-defined crimes, there is a physical, independent actus reus that people recognize as objectively bad and probably intentional. If you didn't steal the thing, if they can't show that you stole the thing, that's now the ground that you're fighting over, and that's much better for the defendant because it's much less fickle.
Essentially it makes every defense necessarily affirmative because the conduct is not otherwise unlawful. The government must dislike you enough to assume bad faith first.
Yep, this is getting blown way out of proportion by all of these tiny scripts that just sit around connecting to themselves. Even pgbench is theoretical and intended for tuning; you're not going to hit your max tps in your Real Code that is doing Real Work.
In the real world, where code is doing real things besides just entering/exiting itself all day, I think it's going to be a stretch to see even a 5% performance impact, let alone 10%.
>So you’re saying that the latest RCS, without the patch, was supposed to be slower than stable by at least 10%?
I'm saying that it's not a reliable measurement of the impact of the PTI patchset. There was a PgSQL performance anecdote [0] (actually tested with the real boot parameters instead of entirely different versions of the kernel) that showed 9% performance decrease posted to LKML, which Linus described as "pretty much in line with expectations". [1]
Quoting further from that mail:
> Something around 5% performance impact of the isolation is what people are looking at.
> Obviously it depends on just exactly what you do. Some loads will hardly be affected at all, if they just spend all their time in user space. And if you do a lot of small system calls, you might see double-digit slowdowns.
So in general, the hit should be around 5%, and "[y]ou might see double-digit slowdowns" seems like the hit on a worst-case workload is hovering closer to the 10% range than 30%. That's also what the anecdote from LKML shows, unlike Phoronix which shows 25%-30% or worse.
This is more of an attrition thing than a staggering loss. With people saying MS patched this in November, it would be interesting to see if people saw a similar 5-10% degradation in Windows benchmarks since that time.
>How often do companies release performance downgrades of that scale?
I don't know which "company" you're referring to here, but substantial changes in kernel performance characteristics are pretty common during the Linux development/RC process, and yes, definitely some workloads will often see changes +/- 10% between the roughly bi-monthly stable kernel releases.
If you're surprised that Linux development is so "lively", you're not alone. That's one of the selling points of other OSes like FreeBSD.
> They run Intel CPUs made within the last ten years so would be subject to this issue.
Do we know that? There is a lot of speculation but the embargo is not lifted yet afaik. There are obviously elements of this that are remaining intentionally obscured pending embargo expiry (redacted comments), so it could be that a smaller contingent of chips are affected and no one is bothering to correct the damage/limit the patch only to applicable components so that the cat doesn't get out of the bag too soon (side benefit: so that an extensive emergency fix like this can be widely tested before it's applied to a relatively limited set of hardware).
Seems just as valid as any other speculation to me.
> They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and the typical jail sentence has been steadily climbing up for decades now.
Insider trading, like many white-collar crimes, exists primarily for its value as a weapon. There is nothing actually illegal about the act of selling a stock; it's all about casting aspirations as to intent and who-knew-what-when.
In other situations, intent is usually an aggravating factor, enhancement, or affirmative defense. It is not the thing that qualifies an otherwise 100% legitimate act as a bad thing.
My anecdotal, unsubstantiated perspective is that insider trading is unlikely to be an issue for anyone who hasn't made enemies, and that it may suddenly become an issue for anyone naive enough to make enemies recklessly. cf. Martin Shkreli, who couldn't be linked to a specific "bad trade" so was brought on generic "securities fraud" instead.
Not playing ball with the people wielding these powers seems to be the dangerous thing.
Phoronix strikes again! I admire Michael's consistency and dedication and their benchmarks have certainly gotten better over the years as PTS has matured, but everything on Phoronix still needs to be taken with a generous helping of salt. New readers generally learn this after a few months; it applies not only to their benchmarks, but also their "news".
The most obvious issue with this benchmark is that Phoronix is testing the latest rcs, with all of their changes, against the last stable version [EDIT: I misread or this changed overnight, see below] that doesn't have PTI integrated, instead of just isolating the PTI patchset. The right way to do this would be to use the same kernel version and either cherry-pick the specific patches or trust that the `nopti` boot parameter sufficiently disables the feature. That alone makes the test worthless.
There is no way this causes a universal 30% perf deduction, especially not for workloads that are IO-bound (i.e., most real-world workloads). This is a significant hit for Intel, but it's not going to reduce global compute capacity by 30% overnight.
EDIT: Looking at the Phoronix page, the benchmark actually appears to use 4.15-rc5 as "pre" and 4.15-some-unspecified-git-pull-from-Dec-31-that-isn't-called-rc6 as "post". I thought I had read 4.14.8 there last night, but may not have. Regardless, the point stands -- these are different versions of the kernel and the tests do not reflect the impact of the PTI patchset.
It is true that now, 22 years after JavaScript emerged as a toy language to allow people to do simple UI tricks like creating alert boxes, and 8 years after people started trying to shoehorn it into the backend for GCool Points, JS has finally started to adopt some useful features. ES6+ address most of the glaring omissions, and writing a script in JS/Node now doesn't feel too much different than writing a script in Python or Ruby (though much more build infrastructure is required; JavaScript is anything but native outside of the browser). Bolting on those features that have been available in other languages for much longer is a big accomplishment from the ECMAScript people, so props to them.
But there are still many instances of people "fighting the language" in the practical sense (the sense that matters). Two main exhibits: Node's "harmony" feature release model that requires the VM to be run with certain flags to enable certain syntax (much worse than Python's `from __future__` model) as well as Babel's entire existence and widespread usage.
I don't know how often you use other languages, but JavaScript is the only platform where I have to run my code through a chain of slow, third-party transformers just to use simple language features like constants with confidence.
Separately, the standard lib is bare and implementations remain inconsistent, requiring everything to be built on struts like lodash and jQuery (with tons of random dangling accouterments pulled from random GitHub repos, a la `left-pad`) that paper over JS's major pain points and general impracticality. Other scripting languages have convenience libraries and wrappers, even alternative implementations, but nothing else goes to the extremes we see in npm, where it's quite common to pull in single convenience functions as libraries.
While these things may not be quite fighting the "language" from the stringent academic perspective of the ECMAScript spec, they do represent practical constraints on virtually all real-world use. Just as you'd be crazy to try to use JavaScript without jQuery back in the day, you'd be crazy to use it now without the huge amalgam of crap people have developed (babel, lodash, webpack, yarn, etc.) because they are so inexplicably committed to shoving the square peg of JS through the round hole of server-side programming.
The intent was not really to get into a detailed deconstruction of JavaScript, it was just to comment on the fad-chasing behavior of the JavaScript subculture, as a follow-on to the parent poster's recognition of this within React users.
I don't understand how any person can pretend that everyone was excited about the "promise" of JavaScript back in the day; you'd have to be relatively new to the scene to earnestly believe that, and as a prominent HN poster whose posts I usually enjoy, I know you aren't. This must be some reverse-psychology thing where you're trying to convince yourself that the emotional fad-chasing was in fact merit-based.
Your points are all backwards-looking. I've already conceded that JavaScript is a major/important platform today and I've accepted that I need to use it in various new ways besides basic DOM manipulation, regardless of the deep sadness for tech culture incurred by doing so. Now that Node.js has ridden the hype train for 8-ish years, there is "great vendor support" and "a huge library".
For the sake of argument, we'll gloss over the facts previously mentioned that a) as "the default delivery platform of the web", JavaScript is still massively constrained, and it's much easier to "deliver" backend applications with a real server-side language; and b) that this "huge library" includes many things that would be part of the standard library in a better-managed language, and that there are a great many undesirable side effects to the npm model of allowing random GitHub users to control huge dependency chains (from both a security and a QA perspective; cf. the left-pad fiasco).
Before V8, even JS inventor Brendan Eich spent much of his time offering excuses for and acknowledgements of its major inadequacies: "I only had 10 days!" and "At least it's not VBScript!" being the primary responses. I don't want to diminish Eich's herculean efforts because they truly are impressive, but the point is that no one pretended that JavaScript was the kind of thing that you'd want to use in any context where it wasn't mandatory. This is very unlike Python, Java, or most other professional-grade languages.
>So this has nothing with Google releasing v8 -- the industry in general wanted faster JS execution.
V8 was revolutionary because it took JavaScript from one of the slowest languages around to the nearly-the-fastest dynamic language (vying with Lua for the crown). The demand was there so that browsers could become a platform for more intensive client-side applications like 3D games. Nonetheless, without Google's propaganda machine turning its gears, V8's announcement would've been relegated to the same small group that followed the release of other JS VMs.
It is completely due to the "I'm cool like Google too!"
mentality (which has had massive influence on tech over the last 10 years) that Node.js got any traction whatsoever. Node.js made its V8 backend one of its primary marketing points to reinforce that association and make people believe that using Node.js was like using a super-cool Google-fied JavaScript instead of the normal, boring JavaScript you knew from the past.
While it may be true that JavaScript has had a large installed base for many years, that installed environment was only capable of operating within the context of a single page load, as long as the browser was open and active, and really was only useful for manipulating the DOM (and JavaScript was a sorry platform even within that ultra-narrow scope).
Node.js changed things by making the platform available on the backend, allowing programs to live longer, but the notion that JS was "important" as a general development solution is incorrect. It certainly was not the "native" or obvious solution for anything beyond manipulating page UI, and this remains the case for the overwhelming majority of the "billions" of devices with JS execution environments. It is still harder to configure Node.js for use on a server than something like PHP.
When I say an "important development platform", I mean that from the perspective of practical use of the technologist, in the sense that the platform is can be expected to host projects that are recognized as clear leaders within a generally applicable space, strongly motivating adoption of the underlying development platform if not already adopted.
This summarizes everything about the JavaScript ecosystem, so it shouldn't really surprise React users that there is no logic behind the community's behavior.
People have finally succeeded in making JavaScript an important development platform by sheer force of will, insisting that JavaScript must become important in order to justify their adoption of the fad. Before this critical mass was attained, there was no real reason to use JS whenever the option was available, and virtually everyone who adopted Node.js and friends was doing it "just to [do] it", in service to the fad kicked off by Google's promotion of Chrome/V8.
Consider that prior to V8, JavaScript was so disliked that the only way to get someone to read a book about it was to name it "JavaScript: The Good Parts". The coder would be surprised to hear that anyone thought JavaScript had any good parts, and would want to figure out what they were, so that his/her days spent in client-side hell would go just a little smoother.
Then Google released Chrome with V8, some people thought this meant JavaScript was cool now, and it's snowballed from there.
IMO, most companies can't engage in anti-competitive behavior independently. You need a special status as a monopoly or a part of a cartel. For normal companies, normal behavior is "anti-competitive" because the point of business is to beat your competitors.
If we assign MS the role of a "typical business" instead of a monopoly (they have may been a monopoly 20 years ago, but it's hard to make that case now), Microsoft is under no ethical obligation a) to provide a client for other operating systems; or b) to ensure that performance parity exists between every client on every platform.
While it may not be super polite to release clients for other platforms and then subtly cripple them in order to drive users back to Windows, there's nothing below-the-belt about it IMO.
While that type of disconnect is certainly plausible, this type of soft communication arbitrage is regularly used to sabotage projects in corporate politics. It allows the conspirators to keep their moves covert. Plausible deniability is key, and affable management personalities go a long way to keeping people believing in the fairy tale.
I'm sure a company like MS, who've had traumatic run-ins with the DOJ in the past, has internalized this phony management persona even more than most. And I do believe low-level developers who work on the individual clients are probably 100% earnest. They usually are. It's the people in the political structure who set their priorities and schedules and use them as pawns that you have to worry about.
Even if your postulation is exactly accurate, MS still bears responsibility for crippling the Linux client, no matter which specific employee the communication "fault" falls on.
I have no inside knowledge of Microsoft, this is just generic commentary and extrapolation on corporate politics in general. It is possible that I'm incorrect and this is truly an honest mistake. If this gets any attention, management will certainly claim that, and we'll never know the reality of whether it was unintentional or whether "The Linux client supports those speedups" was intentionally swallowed by someone along the line (or whether the patch was delayed for additional review because it was "accidentally bundled" with a bigger branch, or whether the priority has just been "innocently" pushed down, or whether the team is "just understaffed", or...).
The proof is in the pudding with corporate politics. Being in management is being a professional politician. That's always true. They're always going to try to tell people what they want to hear and cloud up the picture around things that that person doesn't want to hear. If Microsoft is continually engaging in a series of accidents that hurt non-Windows clients, that pattern is sufficient proof of management's intent, regardless of what they claim.
Although I don't think it's unethical to intentionally make the experience slower for some users, I'm not trying to justify it.
I'm trying to explain that as long as Microsoft's incentives align with making Windows dominant, they're going to engage in behaviors to make it happen, including things like artificially slowing connections from non-Windows machines.
Instead of saying "MS is releasing stuff open-source, they must be having a change of heart", we should say "MS believes that opening this as open-source is the best way to ensure Windows' continued dominance". That's what I'm trying to highlight.
Microsoft's cash cow has always been Windows, and secondarily, Office. That directed their decisions then and it directs their decisions now.
The landscape may change such that Microsoft feels it is beneficial to release things like .NET Core as open-source, but this doesn't reflect a change in what Microsoft values ("A PC on every desk running Microsoft software" and the associated revenue streams), it reflects a change in what they believe is necessary to secure their goals.