pwdisswordfish5

> Basically you want free beer like Linux? Get a distribution from OpenJDK.

After the Oracle lawsuit, why should people feel safe believing that Oracle will respect the terms of the license instead of trying to extract more money and subject you to a costly lawsuit?

> With an internal repository, everyone in your enterprise will be able to view the Page with the same credentials they use to login to github.com

Public service announcement: "login" is a noun; as a verb, you should write "log in". (Consider "knockout" vs. "knock out".) Another thing to watch out for: writing "setup" instead of "set up".

I thought this was obvious.

> You can see the running version at https://bitchin.net

> 502 Bad Gateway

Yeah, it’s written in V.

Scott McNealy, under direct examination on 2012 April 26: "you can't license GPL code and then resell it for a profit"

Source: Official Reporters for the US District Court for the Northern District of California (regarding Oracle v. Google, 3:10-cv-03561)

Just like your last message[1], the answer is "but why male models?" (in other words, I just answered that[2]; do you want me to repeat it[3] or something?)

1. https://news.ycombinator.com/item?id=25847574

2. https://news.ycombinator.com/item?id=25846415

3. https://news.ycombinator.com/item?id=25848980

This is a perplexing response. Oracle's case against Google is about copyright infringement. On that point, you are correct, but that's where your comments part from reality.

Oracle in its case against Google is not arguing that "Java wasn't open-source at the time Google copied it". Oracle in its case against Google is not arguing that there was "a specific license explicitly disallowing mobile use". You on the other hand are arguing these things. That's where the problem lies: you're asserting infringement based on two fact claims that don't even match what Oracle's legal team presented to the courts.

(For that reason, your remark that "Everything else is irrelevant" is just bizarre and ironic—it's your comments here that are irrelevant... _None_ of the things you're saying are what the case is actually about.)

Here are some simple questions: to what extent does your knowledge of Oracle v. Google originate from secondary analysis and commentary about the case vs. direct knowledge (e.g. the briefs and testimony provided by Oracle and those who testified)? Do you have any firsthand experience reviewing the material that was presented in/to the courts? This is the problem with Internet peanut galleries. The answer to the last question can be solid "no", and yet commenters are undeterred from spewing nonsense from their gut that has no basis in reality.

It's like we're not even having the same conversation. McNealy, founder of Sun, testified under oath that GPL doesn't permit commercial use. What was unclear about this the first time it was stated?

This comment is playing fast and loose with the facts. No part of Oracle's suit against Google relied on the claim that "Java wasn't open-source at the time Google copied it" (for good reason).

> they are really bad at shepharding, just look at the state of android java vs openjdk

This has nothing to do with copyright law―the thing that Google was sued for. There is no legal argument in this remark (which is the problem with about half the comments that appear saying that Google was in the wrong), just an assertion based on an appeal to emotion that Google deserved to be sued, and then working backwards from there to present a half-formed argument.

There's no reason to think that you're safe even if it were Apache-licensed. One of the things that was made clear in Oracle v. Google is that Oracle effectively treats litigation as an essential expense for exploring all revenue sources, leaving others susceptible to suits whether they have merit or not. Compounding this latter concern was that another thing made clear is that the terms of the respective licenses is something that Oracle doesn't consider important. Refer to McNealy testifying for example that commercial use of even GPL-licensed work is prohibited (despite the terms of the license not supporting this stance).

This is an argument about checked indexing, not about where indexing should start; after all, whatever the index base, you still need to check that the index fits within the bounds of the array. It doesn’t matter if a behaviour is technically deterministic and defined if it’s not what you want to happen. I mean, just read the explanation of the ‘wat’ talk: <https://stackoverflow.com/a/9033306/3840170>. Every one of these behaviours is defined by the ECMAScript standard, but they’re still useless.

But zero is an https://en.wikipedia.org/wiki/Ordinal_number_(mathematics) .

The unintuitive step is apparently identifying the index with the cardinality of the collection from before the item arrives, not after it arrives – i.e. ‘the n-th element is the one that arrived after I had n elements’, not ‘the n-th element is the one such that I had n elements after it arrived’. The former identification results in 0-based ordinals, the latter leads to 1-based ordinals – and to some misconceptions about infinity, such as imagining an element ‘at index infinity’ in an infinite list, where no such need to exist.

Zero- versus one-based indexing actually matters somewhat for correctness. The real trivial ‘small syntactic technical’ bikeshedding is braces versus indentation (and: which kind of indentation) or semicolons versus no semicolons.

I don’t know why 1-based-indexing supporters insist on pointing out this distinction. Whenever one indexes some kind of a map with numbers – and it actually matters that they are numbers that you can perform arithmetic on, not just opaque symbols – chances are they will be computed from an ‘offset’ somewhere or vice versa, which means the notions are going to blend a lot.

> But we don't need to rely on Dijkstra's opinion at all.

I don’t. I refer to Dijkstra’s opinion because it happens to coincide with my opinion, it’s already written down, and it would be silly to spend effort explaining it over and over again.

IDDQD, IDKFA and I'm in.

It comes with the territory; aiding you in the quest for cool is one of GitHub's only value propositions. Because it's certainly not about productivity. People substitute having a conspicuous social presence for getting work done. Looking around at what everyone else is doing and copying that without thinking about what value it brings. Retroactively insisting they have value with subjective and unfalsifiable claims. It's all part of the tao of GitHub.

It's partially related the webmail-vs-IMAP problem: direct access and control over your data.

An example: There is a pending suit that will ultimately be settled with an insurance company by the courts. Crucial to the case is data collected by a mobile app that helps establish some relevant facts. The incident in question was >1 year ago, and we're going to move forward with the case this week (originally planned for last spring but put off due to COVID). Yesterday, I logged in to the site associated with the app, and it threw up a screen that cannot be dismissed, in the style of "please take care of <these issues with your account> before you can proceed". This is an account which is nowadays dormant, and there is in fact no way to take care of these issues. I dug out my old phone in an attempt to access the records in-app and take screenshots for the benefit of the court. The app itself had had an update released, and the records are now inaccessible, because the old version of the app is treated as an obsolete client. Fortunately, I'd already earlier exported all the data I could readily get my hands on—so the only thing I'm giving up are those screenshots that I determined in a last-minute decision would be helpful as supplemental resources—but this could have been a problem for someone who's never heard the phrase "move fast and break things" and who took it on faith that all this stuff wouldn't just disappear underneath their nose for seemingly no good reason.

If we transition to a world where apps are always writing to (and pulling from) data stores that are under your control, then this would be a total non-issue, even for people less paranoid/guarded than I was. The truth is that there are social hurdles, but there are technological hurdles, too, and dealing with the technological part is a precondition to society being able to be effective in doing its part. People can't solve problems with solutions that don't exist.

Right, there’s still the photorealistic CGI version to be made.

This is nothing more than apologetics, and not even good apologetics. Instead, speculative apologetics, i.e. no solid footing by which to understand the premise.

> I genuinely have no idea what point you are trying to make.

The point, as already stated, is that people who were official mouthpieces for Mozilla said for years that the default search engine simply wasn't up for sale to just whomever would pay for it. That it pointed to Google because Google's search engine was the best search engine for Firefox's users. Just like Google was the default search engine before Mozilla ever signed a deal. Just like Wikipedia was added to the searchbar without anyone paying to make it happen. That any royalties were icing on the cake. (See "serendipitous" in the previous comment). What's hard to understand about this or the earlier comment?

Pfft, please. The staff cuts are among the least offensive things done under the Mozilla name. Much more value was created earlier by unpaid volunteers who were rewarded by having their project hijacked by a Valley-inspired corporate mania concerned with breaking into the mobile market (with a strategy that would be generous to even refer to it as DOA). The size of staff at the time of the cuts is something that only came about because of the absurd growth of the corporation that has became the new face of Mozilla over the last 10 years. Mozilla is an incompetent, bloated organization in need of further cuts still. So it's hard to seriously consider the cuts to be either unfortunate or tragic, particularly given the obnoxious tendency of those on staff to "other" non-MoCo employees whose contributions and involvement predated the layer of corporate sleaze that has come to be emblematic of the modern day Mozilla. Should we feel sorry? The fact that we're even talking in terms of cuts and layoffs means that those affected at least got paid at some point for their role in Mozilla's descent.

The only bad thing about the layoffs is that Mozilla leadership was shitty enough to do it during the middle of a pandemic. At this point though, keep it coming. It's been a bittersweet experience watching the tide turn against Mozilla over the last year, as the popular perception of it has only just now begun to align with how unworthy of an organization it has been for years already.

> in 2015 Mozilla negotiated a deal with Yahoo netting them an additional $100+ million

... after spending years saying that the relationship with Google regarding search royalties was a serendipitous one that involved getting paid for a decision that was the right thing for users whether money was changing hands or not, and that the default search engine spot wasn't actually for sell.

That lie is not unlike their carefully crafted PR statements that were intended to mislead people about the financial arrangement regarding the Pocket partnership. Those efforts turned out to be so successful that they hoodwinked many of Mozilla Corporation's own employees—who interpreted the statements to mean that there was no financial incentive, just as it was intended to be interpreted by the general public. Then those employees began showing up on places like HN and started saying explicitly that there was no money changing hands, even though that's not what the PR statements ever said and reality actually differed.

Once upon a time, someone affiliated with Thunderbird project maintenance/governance posted a detailed reply to HN describing how hard it was to get Mozilla to release funds that it had been been collecting from Thunderbird donors. That comment is obviously not lost to the sands of time, but it has proven quite difficult to relocate.

gcc and g++ use the same backend.

JavaScript became successful simply because it was the only real choice, and it would have been so even if it were less permissive. VBScript’s failure stems mostly from the fact that only Microsoft supported it (and as I remember, it wasn't even particularly well documented).

I share your childlike optimism. But another thing (that neither of the sibling comments mention) is write speed. Having a ton of capacity to store massive amounts of data at rest is not the same thing as being able to easily make near-instantaneous (or even slow) copies. Getting all that data on there is going to be a problem, and so it would only be economical for data sources in high demand, not unlike the way that optical media get the pits and lands stamped in at the factory based on an expensive master. "All of YouTube" might be (probably is) in high enough demand, but it would also require cooperation from the gatekeeper of that content, who at this time has adverse incentives because it's making (many times) more money selling ad impressions for basically every view that it's able to. Even aside from that, what other large datasets are in the same demand category such that the work could or would be subsidized in that way?

    int ftruncate(int fd, int64_t length) {
      if (!IsWindows()) {
        return ftruncate$sysv(fd, length);
      } else {
        return ftruncate$nt(fd, length);
      }
    }

You get the idea. The OS is detected at startup and then checked each time a function is invoked.

It’s a libc implementation accompanied by a linker script that tricks the linker into generating a polyglot executable file, simultaneously interpretable as an MZ executable, x86 boot sector and a Unix shell script, the latter of which re-writes the executable into ELF or Mach-O format and then executes it again. I haven’t analysed it all that thoroughly, but that’s the gist of it. Here’s more information: https://justine.storage.googleapis.com/ape.html

Polyglot files are not a particularly new invention, but devising a reproducible process to generate those can be quite tricky, so most don’t bother unless there’s a special need for it. (For example, the GRUB4DOS fork of GRUB contains a ‘bootlace’ executable that is simultaneously executable as a DOS .COM and an ELF file.)

The libc itself contains a number of specially-crafted functions and header files that expose the functions’ clobbered register set as part of the functions’ public ABI, which allows the compiler to use that knowledge to better allocate registers and optimise more aggressively. The downside is that if the clobbered register set changes, it requires everything using the function to be recompiled.