It's an odd term, but one that inadvertently brings attention to concerns such as privacy and identity persistence.
Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.
Sometimes it really shows that many early Wikipedia articles were someone's labor-of-love about a relatively obscure topic, and even today there's uneven levels of notability across the encyclopedia.
Instead of these hyphenated iron laws of transportation demand that no one has ever heard of that all say the same thing, the article of "induced demand" ought to suffice, and these formulations, if they exist original sources at all, ought to become references in that article's footnotes.
Almost all "deletion for non-notability because I've not heard of it" reasons should be invalid. Wikipedia deletes far too many people's work in the service of a small number of core maintainers.
First why is granularity at the level of induced demand ok, but not the Lewis-Mogridge position? Why not put it all in the supply and demand page?
Second, if I come across the Lewis-Mogridge position, and Google it not knowing what it is, should I expect, and prefer, a link to a research paper, a broad wikipedia page most of which is irrelevant to my question, or an actual page that answers my question?
Personally I'm a wikipedia maximalist. Record everything, keep it around for posterity. If in 50 years they want to know what we thought about X, they can find out, and we today can reliably find out about X too.
The clearest benefit of conferences for developers is networking and the "hallway tracks" -- the emergent discussions that arise after talks. The social processes of these are hard to replicate online. The asynchronous nature of online text chat, perhaps the most apt widely-deployed alternative, already lessens the urgency and spontaneity of the discussion. There are people who don't take advantage of the opportunities to insert themselves into emergent conversations, and unless their presence alone is a positive signal for the company, they're largely wasting their company's money.
The clearest benefit of conferences for sponsors is the potential lead between frontline-but-backoffice workers who work on a particular topic to the decision-makers behind them who can influence purchasing. Being present at conferences fosters passing familiarity of developers with the product, which helps conversations that occur between those developers and their bosses later: the emails from the higher-ups that ask "what do you think about Product?", and the off-the-cuff gut assessments that follow. Irrespective of the developer's initial reaction, name recognition of the product sticks around and often makes it to later rounds of evaluation and assessment.
Absolutely! 'LobbyCon' (colloquial name for any 'Con discussions in hallways or lobbies) is a thing. I can't really get anything like that online, regardless the platform. The closest, which is a longshot, has been IRC.
Sure, you can attend talks... However "magical" things happen when you get people with different skills all talking as equals. It's the opposite of mob mentality, where each person in a group adds to the collective intelligence and power to see further.
And yes, I just got back from Circle City Con in which I gave a talk about "SigInt for the masses: Building and Using a Signals Intelligence Platform for Less than $150". For me, it was a 1hr drive. But still, watching a video or making one online != in person.
This whole case is contrived, and both actors acted in bad faith, so the outcome will be troubling no matter what.
If Oracle wins, others can claim that their API is copyrighted and weaponize copyright law to sue anyone they don't want to interoperate with them -- despite the whole point of APIs being that interoperability.
If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation, like they've done with Android. To protect against this, patents and NDAs will proliferate, and black-box organization and SaaS business models will solidify as the only (commericially) sensible way of distributing software.
How did Google "hijacking" the Java API harm Oracle? If it didn't, why should anyone need to "protect" against such a thing happening in future?
Maybe I'm missing something, but your comment seems to boil down to "If Oracle wins, people won't be able to copy APIs, which is awful! If Google wins, people will be able to copy APIs, which is awful!" Surely you have to be on one side or the other?
It segmented the Java ecosystem into two parts. Android doesn't keep up-to-date with current Java version changes and creates friction. It seems similar to what Microsoft did to Java in the late 90's [0] (without the malicious intent).
I'd argue it vastly expanded the Java ecosystem, and the original part is unharmed. It's not necessarily getting unearned growth from the success of Android, but at the same time it's a huge stretch to say it was harmed.
Sun did that themselves with Java ME. In 2008 when Android was released the newest version of Java SE, Java 6, was released in 2006. The newest version of Java ME, however, was 1.3 released in 2000.
Java ME was 8 years out of date before Android was released.
And Java ME wasn't even one platform. It was a collection of optional extensions.
Mobile phone companies used to license Java from Oracle. Instead, they all now use Android instead, a ripped off implementation of Java. Oracle claims they had intentions of moving further into the smartphone space (most mobile Java implementations a decade ago were on dumbphones, AFAIK), but Android shot their plans and the value of their purchase of Java to heck.
In short, Oracle has claimed they bought Java from Sun to make a mobile OS that would've been licensed to manufacturers, and by stealing the Java API from them, devalued that purchase by launching Android for free.
Having coded for Android and JavaME, I can say that JavaME would have never worked right in the smartphone space. It's whole process lifetime architecture is wrong for smartphones. It basically only works with one app running that gets killed on quit otherwise you kill your battery as if your phone doesn't go to sleep.
In fact, the law is intended to protect your business from competition, when that competition is repackaging and reselling your original work. That's the entire point of intellectual property law.
Prior to all of this, for practically a decade, open source projects had been reimplementing parts of Java. For example, I used Java for coding on the original Palm Pilot via Ghost (http://www.cs.utah.edu/~mcdirmid/ghost/) and SuperWaba projects. (https://en.wikipedia.org/wiki/SuperWaba) No one had any problem with this activity prior to Oracle, not even Sun, it was pretty much established a long history that this was acceptable behavior, Sun even encouraged it to some extent, as long as you didn't call the result Java(TM).
Mobile and embedded environments can't run the full Java, and Sun's attempts at this (Embedded Java, Personal Java, MIDP/Jave ME) were awful. Oracle's claims that they were going to make a competitive mobile OS are dubious at best. I joined Oracle's Mobile division in 2001 until 2006, and at the point I left, my impression was that they were more or less wrapping it up, and merged the OracleMobile division back into Oracle Collaboration Suite to work on Enterprise apps like Calendar and Mail.
It is much more likely, given Oracle's history, and the public statements of James Gosling, that Oracle was more or less interested in purchasing Sun's customer base/rolodex, and patent portfolio to shakedown. They had no interest in Sun Labs, Solaris, UltraSPARC T1/Rock/MAGC, or making products out of any of cool tech Sun had developed. Sun had a lot of customers who would buy expensive Solaris boxes, who would be prime customers for databases and ERP software.
The computer industry got its start in spite of copyright, not because of it. Homebrew hackers cloned commercial systems. PC clone makers cloned IBM's BIOS. Intel clone makers clean room cloned x86 chips. Piracy was rampant, and it was the primary way other engineers learned. In the early days of the Web, the very nature of "View Source" allowed everyone to copy everyone else's Website, their markup techniques, their CSS, their Javascript. Again, it is how people learned, how the ecosystem evolved.
Look at what you're doing, someone who has claimed support for OSS in the past, you're supporting the argument that a corporation (Oracle), known for taking a buzz saw to acquisitions to get their customer base Gorden Gecko style, who ships mostly badly engineered software, poor poor Oracle, had their plans for a licensing shakedown, foiled by someone creating a viable smartphone OS that has enabled literally thousands of OEMs to build a vast ecosystem of devices for free.
Would you say the same thing about the developers of WINE if it actually started making an impact in Windows value? What if Google held a copyright over some Web APIs (perhaps Widevine video DRM stuff) that every website used, and they sued Mozilla over a cleanroom implementation that devalued the acquisition, would you be against Mozilla?
I'm literally shocked by anyone taking the position that clean-room API reimplementations deserve copy protection, especially people who claim to support OSS, and anyone defending the rights of $100 billion market cap companies to own API copyrights. This isn't some small time 3rd party library developer being deprived of living expenses. The ability for clean-room reimplementations to happen is how we break monopolies, its how network path-dependencies get disrupted by providing inter-rim migration paths. It's the entire history of the computer industry. It's how Coherent cloned Unix.
GNU and Linux largely cloned AT&T's existing Unix suite of tools in user space. These are essentially APIs, and their organization and collection, certainly represents a creative endeavor. If we were to accept this defense of Oracle, we would be forced to conclude that Unix was massively devalued as well.
The fact that competition that executes better on your idea than you do can devalue your product should not be a defense to have government and courts intervene on your behalf.
As a supporter of open source software, I wholly support Oracle's fight to catch Google trying to evade the GPL. I'm not sure how an open source supporter could really be supportive of your employer lifting from the paid version of a product to avoid having to comply with the GPL. Google's actions here pose a massive threat to anyone who has developed open source software funded by a commercial licensing option.
What I find dubious is not that Oracle might try to make a mobile OS (your argument against this is the subjective opinion that it was "awful"), but Google's claims that their use of the Java API was "fair use". Building a non-interoperable competitor for commercial licensing based on their work doesn't come anywhere near the terms of fair use. By Google's own admission, the choice to do this was an attempt to leech off of developer familiarity with Java rather than any sort of compatibility need.
Open Source -- as in Source Code. GPL protects source. The stuff you actually fork when you type 'git clone'. You really think Richard Stallman would be opposed to someone cleanroom re-implementing a GNU GPL'ed software from scratch that has a compatible API? Stallman called Android a major step forward, and if anything, his problems had nothing to do with subsetting Oracle's API, but issues surrounding Tivoization and binary blobs.
java.io, java.util, java.lang are re-mixes of every other OO runtime going back to smalltalk. I'm not buying this idea that reimplementing List, Map, Set, InputStream, et al, without copying source needs protection.
Moreover, the fact that oodles of subsets of the Java APIs existed for a decade, and Sun never once took any of them to court, buttresses the argument that the CREATORS of the API were not interested in protecting against reimplementation. Even GNU Classpath wasn't a proper fully compatible version of the Java APIs, it could not pass the TCKs, but Sun did not threaten it.
Yes, Google likely chose Java because hundreds of thousands of developers already spoke it. Just like Objective-C choose C and Smalltalk, because so many people already spoke it. What's wrong with building a system that will have a low learning curve and easy to transition to if it is very similar to what people already know? C# was created by Microsoft to resemble Java for similar reasons.
Arguably, APIs have been found copyrightable, and the solution is simple: Include a license with your API. In a lot of cases in the modern era, APIs have terms anyways, because they're tied to web services. So adding a clause about being able to implement them is trivial, for any intended use of an API.
The main difference is that developers will have more tools to fight unintended or unwanted uses of their API, such as clones, emulators, scraper tools, etc. There's concerns to be had, sure, but it's not the end of the world by any means, and a lot of those will fall under fair use in a way that Android does not.
> If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation
Hijacking means taking control away from someone, I don't see how that happened here.
The Supreme Court mostly isn't about which side wins. They could come up with a useful way to adjudicate which wouldn't lead to either of the sets of costs you mention.
Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.
What? You mean protected by the _MAC_? The header is never encrypted: the header is how you even figure out what to do with the rest of the message at all. That is why it definitionally can not be protected by it (that's the definition of the cryptographic doom pricnople!) and is how the bugs I am referencing are exploited to begin with. The only sense that a JWT header is "protected" is that the spec calls it that.
Have you ever exploited a JWT vuln? Which one? Because odds are there's a way it boils back down to the JWT header design choice being silly.
I mean there's an easier way to have this conversation: if the header is "protected", how did the alg=none bug ever work?
In a JWS the header is integrity-protected by the signature if the alg isn't none. This is prominently noted in the specs and alg=none artifacts are referred to as "unsecured JWS". In a JWE the protected header is integrity protected by the AEAD cipher, because all encs must be AEAD.
The alg=none substitution issues happened because of bad usage of mediocre libraries. Other algorithm substitution can arise for the same reason. The invalid curve attacks were the ones that the spec didn't call out as a security consideration.
I support the arguments that say algorithmic agility is a bad idea and a new protocol with algorithmic agility shouldn't have come out at a time when other protocols (like TLS) were finally starting to catch on to this fact. But the JWT cat is out of the bag, and won't go back in: it's widely deployed and people are using it thinking it's solving problems they actually have. Education is the proper remedy.
The PASETO effort attempts to provide better answers and better design to an audience familiar with JWT, but there's also been an uptick in the kind of advice that heavily condemns JWT without supplying some migration paths. That latter brand of advice is harmful.
Same points I made before: if more than one library has a flaw, it’s a design flaw and not a one-off implementation flaw, and if you’re trusting the header before you validate (which is necessary!), then it is not meaningfully protecting anything, which is why those bugs work.
And, finally: we’ve put together an extensive list of recommendations, repeatedly, both in general and in the articles on this thread.
Much of the ahead-of-the-curve, aspirational tech stack posts featured on HN are the blogging equivalent of Instagram-polished shots. On a personal blog they're equal parts self-expression and self-promotion; on a company blog they're equal parts deep dive and recruitment teaser. It's okay. Some readers will feel intrigue, some confusion, some envy. They'll wonder why they can't use those new tools at their work.
It's nice to recognize there exist developers who seem to stand apart from the vocal ones who make these posts, but they're not a single class. Some brag just as much, just in different circles. Some don't brag, but they do lots of good work. Some put out work that's not so good, and they may or may seek to represent their accomplishment regardless. The only factor they clearly share is their underrepresentation and their lack of attained popularity in talking about their work on social media.
As tempting as it may be, it's a big reach to conclude due to their underrepresentation that their tech stacks are conservative, or even dated; it's not a given that their work is solid and they're hard at work solving business problems given numerous constraints and office politics. Efforts to define this population by their rejection of shiny hype just perpetuates a kind of fictitious class divide between "fancy" developers and "plain" developers, when the real class divide is between management that is desperate for results, and IT workers that are desperate for empowered decision-making and resources. Businesses are under tremendous pressure, and silver bullets read about elsewhere carry great appeal. Transplanted organically by enthusiastic developers or by order of management, such solutions rarely work, because changing just a few inputs of a complex process won't deterministically give a better result. And mediocre results of a messy process make for a different genre of writing.
Maybe there's a class divide after all: between developers who are privileged enough to cook up all sorts of clever, custom solutions to challenging problems and can write about it, and those who spend their whole workday surviving the onslaught of nonsensical demands and deliver something mostly working in the end.
See the history of the Stabilization Act of 1942 [1] and Executive Order 9250. Wages were frozen by law, but not benefits, so companies began offering benefits, including health insurance [2] The next year the IRS decided these were nontaxable, until it changed its mind in 1953, only to be overruled by Congress in 1954 [3].
I didn't see 'cash management accounts' on the list, but I think these are among the best products. They're not too common, but more are appearing now.
There's the classic ones that combine various investment products and slush balance that's insured by a bank sweep in the same interface, and the new ones that abstract completely away from the underlying storage of the money, and provide some familiar features (debit card, bill pay, ACH transfers) and perks (high interest rate, no fees).
The latter kind is a great, low-risk, low-effort store of spending money for people with unpredictable income and/or spending who have little time or cushion to invest in products with higher returns and need the liquidity. It's a compelling alternative to a traditional US checking account at a large bank, where most of this demographic has their money.
Is this disruptive? Fidelity and Schwab both have great, free, cash management accounts that refund all ATM fees domestically (Schwab even refunds international ATM fees, making it great for nomads).
It's disruptive as this kind of product moves downmarket, at least in the sense of mindshare and marketing, if not always in terms of customer segment. These accounts may be common knowledge among people who invest online and interface with brokerage firms, but others might not know about them.
The recent marketing tactic by newer firms is to convince people to migrate from checking and savings accounts, to catch the demographic that has (for whatever reason, presumably related to cashflow, lack of info, or generational anxiety) already decided that online investing may not be for them. Perhaps they'll change their mind once they're past your acquisition funnel.
I can throw in my 2 cents here as a Schwab customer.
Schwab will let you buy CDs at any bank via a brokerage account linked to your checking or savings. Basically, they'll transfer the money to whatever bank has the CD you want, and transfer it back to you with the interest at expiration. Ditto for T bills. It's an excellent product to increase yield without taking on default risk
PayPal Cash Plus has a ton of features, but there's lots of fees [1][2]. You earn no interest. It's not a good deal, other than it being familiar.
Square Cash, now known as the 'Cash' app, is a strange hybrid of a P2P payment network and a spendable balance that gives a debit card and you can direct deposit into. You earn no interest. It's odd. It targets a hip young consumer who wants ease and convenience and doesn't know any better. It has... some... virtues? Just not ones that make it worthwhile to use it instead of some rival that earns interest.
Depending on your exact use-case, it will vary which one of these is ripoff-tier and which one is so-so. I have a low opinion on nickel-and-diming fees for convenience features, so I find the PayPal Cash Plus offering the most grievous. Square Cash just has a weird use-case that isn't my use-case.
Thanks. I use Square Cash to pay the cleaning lady on occasion, so I guess that's one use case. I suppose if I kept more of a balance I would look into interest rates and all of that
I use Schwab investor checking. I love the free ATMs and saving on international fees. BUT it does not give any meaningful interest on balance and it's hard to get cash.
I do LOVE the support. Compared to my other bank's Visa card it's completely different support and Schwab is hands down way better. It feels like 'wealthy important person' support lol
I also use Wealthfront and Robinhood and recently put a small amount of cash into Wealthfront's high interest cash account. The problem is there is no card or similar spending functionality, and Treasuries seem to pay slightly more and similar time to 'liquid usable cash'
Tumblr's adult content ban was likely a last-ditch effort by Tumblr, encouraged by owner Verizon, to salvage some business value out a hectic social (re-)blogging site that seemed like a questionable fit even for the previous buyer Yahoo.
Verizon embarked on an ambitious effort to be a force in online content and display ads, so that they'd produce worthwhile content that would contribute to them running a bigger and more successful ad network. They bought AOL and its magazines to make it happen, and a few years later they acquired the content arm of Yahoo when Yahoo pivoted to an investment holding company.
Porn blogs were a big and visible part of Tumblr, but Tumblr's unwillingness to use coarse filtering meant that they were poorly policed. Porn blogs were overwhelmingly run by bots and hosted stolen content, they'd spam-follow unrelated accounts to game search engines, and they'd generally be a nuisance in every way, despite attracting a fair amount of viewers. The Apple App Store fiasco gave a convenient pretext to roll out the coarse filter to whack porn blogs and make the site more palatable for advertisers, but the collateral damage also affected erotica, art, sex-positive communities, and various LGBTQ communities. Meanwhile, ads on Tumblr have gotten a slight bit more frequent since the Yahoo days, but hardly any more relevant or less low-rent.
The author is clearly passionate and brings a lot of detail, but it was always my amateur impression that Walmart won primarily on footprint. They covered the country in stores, and not just the suburbs, but also rural America where the likes of Target and Kmart never ventured, and shops with much smaller selections and different formats were the norm.
I don't perceive Amazon as an 'unbounded' Walmart like the author does, but as an aggregator as thoroughly analyzed by Ben Thompson of Stratechery fame. They bootstrapped a destination with undifferentiated products, a broad selection, and convenience, and later bolted on a marketplace to further capitalize on the traffic. But the dynamics of customer-facing marketplaces are very different from those of internal ones like those of Walmart and McDonald's. McDonald's puts out specs and has suppliers compete for restaurants' buys, and Walmart and Costco have immense purchasing leverage with suppliers, this process results in optimizing the desired quality-to-cost ratio the retailer wants to target.
Amazon, on the other hand, is a free-for-all, where selection is overwhelming, products with obscure branding appear to rip each other off to the point where no obvious choice rises above, human curation is absent, reviews frequently appear gamed, prices change arbitrarily, products are gated behind Prime and are subject to obscure shipping math, and despite being long perceived as having low prices, pricing on products is now being used as a signal. Amazon is hardly anything more than a digital flea market, where Amazon is the landlord and some of the vendor booths are staffed by them directly. A wildly successful and profitable one, and one that draws marketshare away from traditional retail, but it diverges so far from the formula of retail that comparisons with them are of questionable value.
Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.