niftich

According to WHOIS, w3c.org is from 1997 while w3.org is from 1994.

A message from a W3C staff member on a W3C mailing list on 1999-06-21 mentions [1] that w3c.org should redirect to the corresponding page at w3.org, and the latter is considered the 'correct' domain.

[1] https://lists.w3.org/Archives/Public/www-rdf-comments/1999Ap...

Fielding's thesis [1] talks about this.

Here's some selected quotes:

6.2.1 "(...) The definition of resource in REST is based on a simple premise: identifiers should change as infrequently as possible. Because the Web uses embedded identifiers rather than link servers, authors need an identifier that closely matches the semantics they intend by a hypermedia reference, allowing the reference to remain static even though the result of accessing that reference may change over time. REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created. It is then left to the author to ensure that the identifier chosen for a reference does indeed identify the intended semantics."

6.2.2 "Defining resource such that a URI identifies a concept rather than a document leaves us with another question: how does a user access, manipulate, or transfer a concept such that they can get something useful when a hypertext link is selected? REST answers that question by defining the things that are manipulated to be representations of the identified resource, rather than the resource itself. An origin server maintains a mapping from resource identifiers to the set of representations corresponding to each resource. A resource is therefore manipulated by transferring representations through the generic interface defined by the resource identifier."

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

This is one of those classic, foundational documents about the Web. But it's rarely followed. Tool use has come to dominate the form that URIs take; tools are used both for delegation and to absolve humans from crafting URIs by hand. Switching tools frequently ruins past URIs.

Additionally, widespread use of web search engines has made URI stability less relevant for humans. Bookmarks are not the only solution to find a leaf page by topic again. A dedicated person might find that archiving websites may have preserved content at their old URIs.

Some of this is allowed to happen because the content is ultimately disposable, expires, or possesses limited relevance outside of a limited audience. Some company websites are little more than brochures. Documents and applications that are relevant within organizations can be communicated out of band. Ordinary people and ordinary companies don't want to be consciously running identifier authorities forever.

This basically exists, and it's called ISO 8601. But the scope of ISO 8601 isn't programming languages and APIs, but data models and their representations. A subset of ISO 8601 forms the basis of RFC 3339. Official copies of ISO 8601 are available for a fee from ISO. For the purposes of this discussion thread, consult this file hosted by the US Library of Congress for reference [1].

ISO 8601 defines a number of terms of art to represent a thorough mental model of the problem space, and then goes on to define string representations on how to express them. But it's paywalled, so people reach for RFC 3339 and the Wikipedia article instead. These focus on representations, and the definition of the concepts isn't captured clearly, so sometimes they're rediscovered independently. Other times, they're not.

Serious attempts to figure this out usually coalesce to something that looks and behaves like Java 8 time. Java 8 time may be verbose, but its concepts are clearly mapped out, and the API bears some marks of a misuse-resistant design. Compared to that, there's efforts like the standard libs for Python, Ruby, Go, or most third-party libs for JS, Rust, that don't bring clarity to the table, and don't present any solution for dealing with calendrical or clock-face objects, and do little to discourage misuse of their point-in-time objects in abstract contexts.

This proposal falls much, much closer to the Java 8 way than to the "everything is an instant, go make your own classes" way.

One shortcoming of ISO 8601 is that it has no provisions for abstract timezones. Instead, people go outside of the standard to represent ISO datetimes alongside IANA timezones.

But the most glaring problem with ISO 8601 is that it doesn't define partials where a more-significant term is unknown or missing: there's no valid, unambiguous way to refer to the 15th day of March, while leaving the year deliberately unspecified. This means that anniversary dates (e.g birthdays, holidays) aren't possible to represent in the abstract.

Likewise, there's no valid, unambiguous way to refer to the 29th second of the fourth minute of every hour. This is much less important than the birthday shortcoming.

The Library of Congress has a standard which extends ISO 8601 with a number of useful constructs for their purposes [2], like uncertainty qualifiers, but even that standard has no mechanism to represent a month+day partial in the abstract.

[1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... [2] https://www.loc.gov/standards/datetime/

In 2005, Ed Russell and Frazer Jarvis calculated 5,472,730,538 "essentially different" 9x9 grids [1][2], once they've excluded valid grids that can be derived from another valid grid using relabelling, various permutations, reflection, rotation, etc.

[1] http://www.afjarvis.staff.shef.ac.uk/sudoku/sudgroup.html [2] (PDF) http://www.afjarvis.staff.shef.ac.uk/sudoku/russell_jarvis_s...

SipHash was specifically designed to be resistant to hash flooding attacks.

FWIW, the SMHasher test suite takes the view [1] that defense against hash flooding attacks is a concern for the hash table's collision resolution method, which is a fair point. Nonetheless, SipHash was subsequently adopted by several programming languages' standard libraries for use in hash tables. SipHash is also notable for its clear and concise specification, including security claims, preliminary cryptanalysis, and a discussion on hash flooding [2].

[1] https://github.com/rurban/smhasher#security [2] https://eprint.iacr.org/2012/351.pdf

Depends on your use-case and the tradeoffs you're willing to make. SHA1 is slower than the the top finishers of the SMHasher suite [1], even if it's hardware-accelerated. Meanwhile, SHA256 and later are currently considered to be suitable for cryptographic use, so if you're not sensitive to the size of the hash output, you may get additional nice properties that you didn't intentionally design for. But they're even slower.

If you're shipping a black-box component that needs to use hashing internally, and the hash outputs don't leak out of the black-box, consider switching to a faster non-cryptographic hash to gain performance. Consider the implications of switching -- dependencies, trust, performance profile, hash output size, documentation, customer expectation -- and you will have to discard or otherwise invalidate the meaning behind of your past hash outputs.

If you're occasionally applying a hash function and obtain a digest that gets put into long-lived files or records, e.g. you're checksumming your own files for sanity and then verify them later against these records, then you may value availability and stability more than you value performance. If so, don't switch.

If you are fine with the current performance profile, the cost and complexity of switching (or any nontrivial change) may outweigh the benefits of leaving everything as-is.

[1] https://github.com/rurban/smhasher#summary

This is a hash designed for non-cryptographic use, like in hash tables or bloom filters. You can tell by their small output size, which greatly reduces the cost of a brute-force collision search. It's also in the linked readme.

Hash function families with a similar target usecase include: cityhash, falkhash, farmhash, FNV, meowhash, metrohash, murmur, t1ha, wyhash, xxh.

The SMHasher suite tests hash functions for speed, distribution, bias, and collisions. This function ranks well in those tests.

This works sometimes. Like, the article notes, it worked for the iPod. For the iPad, it landed much softer than its predecessors, even if they still made a killing on sales.

The large format was awkward to hold as a content consumption device, and while it could have made for a neat content creation device, that never became a mass-market phenomenon. Later, smaller models were then eclipsed by phones that grew in size. Then, recently, the line was repositioned to import some more traditional computing expectations, after the Surface line proved that there was demand for that paradigm.

If you squint, you'll notice that the iPad wasn't a failure, but the critiques leveled against it at the time that challenged whether consumers would recognize that an iPad was something they needed turned out to be right. Those who waited and never bought an iPad were rewarded by phones that grew in size until they could reliably satisfy much of the iPad's usecase. Those who used the iPad for content creation found that software was a significant part of their workflow, which translated poorly to competing platforms that later emerged to innovate with hardware -- so their long-term retention was a blend of lock-in and merit.

At first, the high price of the product initially contributed to a significant self-selection of its customer base -- by dissuading unsure prospects from an impulse buy; but this gatekeeping effect was lessened when smaller, cheaper models were introduced later. Gmail achieved gating through invitations; Facebook achieved gating through requiring an ".edu" email address. The iPad, Gmail, and Facebook all benefited from the marketing value of gating, but in the latter two's case, the network effect kicked in in earnest once the gating was lifted. In the iPad's case, once less-invested people began buying iPads, that now-shifting market of people began moving closer and closer to the consensus that it's simply a Really Big iPhone, with all the benefits and drawbacks that come with that.

I'd generalize that lesson to say that your product must appeal to a self-selecting, highly-invested fan, so that it's profitable to solely cater to them and ignore everyone else. Then, to survive an intentional or unintentional pivot to a more mass-market appeal, your product must readily offer a smooth and coherent way to satisfy a set of usability needs people currently have. Gmail, Facebook, the iPod, and the iPhone did this, but the iPad fell well short.

He's speaking from experience. But, if your circumstances aren't exactly the same, the outcome may be different.

Credits pages in software, accessible from the main UI, used to be very common, and having names there -- or embedded in source code -- doesn't violate a user expectation.

Server software sending 'Server:' headers also doesn't violate user expectation, though some people prefer to turn these off.

Custom headers that cannot be turned off have a higher likelihood of violating user expectation.

To the OP: in open source projects, some users will attempt to remove undesired behavior, within the rights afforded by the license, but these exercises of copyright can interact adversely with trademarks and other brand protections, and with the surrounding (human) infrastructure and information-space around a project (e.g. names, URLs, references to services, secrets).

Your attempts to reconcile such a situation are nontrivial, and both inaction and action have a high likelihood of resulting in bad press (e.g. user confusion about fork, or heavy-handed enforcement). The harm will persist long after the original situation has been resolved or mitigated.

With Spring Core (the DI container) the only parts of your code that have to depend on Spring are the config and your entry-point.

You can choose to import facade-style Spring libraries, and write your code against them -- like Spring JDBC, Spring JMS, TaskScheduler -- if you want something that does some heavy lifting for you, but doesn't tie you to a vendor implementation directly.

Meanwhile, Spring Boot is a fully-opinionated framework based around the combination of defaults and on-the-fly auto-configuration, and giving you a single runnable uber-JAR at the end. And you're right about it: if you're using Spring Boot, it makes sense to depend on other Spring libraries, because (1) the docs guide you into them, and (2) the two will interact to auto-configure. For example, you can just run your DB code, and it can auto-configure an in-memory instance as you're developing [1]. Then, when you've gotten the real database, just specify the real config.

Spring Boot really shines in bootstrapping a greenfield project to get going quickly, especially if you're willing to compile its annotations into your code. You can then go back and incrementally override behavior and configs once you realize you want them a certain way.

[1] https://docs.spring.io/spring-boot/docs/2.2.7.RELEASE/refere...

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow.

The way you use the core inversion-of-control framework people often just call "Spring" is you take your homegrown, doesn't-depend-on-Spring business logic, you make a config file, and if you're not executing it a servlet container, you make one entry-point class to start it all up [1].

There other projects under the Spring umbrella, and some of them are meant to be called from your code. Like Spring JDBC for database access, whose framework-like nature is apparent, yet in terms of its usage pattern, it resembles a library [2].

[1] https://docs.spring.io/spring/docs/current/spring-framework-... [2] https://docs.spring.io/spring/docs/current/spring-framework-...

See document FCC-20-48 [1] for full text. Some quotes:

"Our decision authorizes Ligado to deploy a low-power terrestrial nationwide network in the 1526-1536 MHz, 1627.5-1637.5 MHz, and 1646.5-1656.5 MHz band (...)"

"Our action provides regulatory certainty to Ligado, ensures adjacent band operations, including Global Positioning System (GPS), are sufficiently protected from harmful interference (...)"

"Ligado's amended license modification applications significantly reduce the power levels of its operations from its earlier proposals and commit Ligado to providing a significant guard-band in the MSS spectrum to further separate its terrestrial transmissions from neighboring operations in the Radionavigation-Satellite Service (RNSS) allocation. Based on the extensive record, we conclude that Ligado's latest proposal—combined with the stringent conditions we adopt today—addresses harmful interference concerns with respect to GPS operating in the adjacent RNSS allocation, as well as concerns with respect to MSS licensees' operations in the L-band."

Read section "II. Background" for more technical info and changes since the LightSquared proposals.

[1] (PDF) https://docs.fcc.gov/public/attachments/FCC-20-48A1.pdf

As posted by someone downthread [1], there's an ongoing effort to update the OAuth 2.0 spec with changes since, lessons learned, and best practices [2], in what's currently being called OAuth 2.1. Some more rationale and resources on oauth.net [3].

[1] https://news.ycombinator.com/item?id=23083245 [2] https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02 [3] https://oauth.net/2.1/

OIDC is for authentication and profile information. The standard claims refer to each field of profile information [1].

It doesn't include any domain-specific operations like your examples.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Standa...

A drop-in component so your product can do what exactly?

To be an OIDC Relying Party [1]?

To be an OIDC Provider [1]?

To be an OAuth2 client [2]? Keep in mind, being an OAuth2 client is probably not useful by itself -- you'll have to program your app to deal with the resource server's specific APIs to accomplish anything, and request the appropriate scopes for the situation, based on what you're doing.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Termin... [2] https://tools.ietf.org/html/rfc6749#section-1.1

Client registration is so that (1) the authorization server can obtain the client type (confidential or public), then, (2) if appropriate, obtain the client's Redirection Endpoint URI, so that the authorization server's authorization endpoint can avoid needing to be an open redirector, and (3) to obtain any metadata that the authorization server will display to the resource owner just prior to them approving or denying the authorization request. The spec explains this [1].

Also, service providers who are custodians of the resource owners' data want you to be accountable to them and their users, so they want to have some information about you.

There's a proposed standard for dynamic (and/or programmatic) client registration [2]. While there are some interesting use-cases, it offers little benefit to a service provider who wants to vet clients (or appear as if it did).

The spec contains some design recipes if you want a loose association between which clients are allowed to receive data the user approved (i.e. implicit grant), if you care little about whether the user trusts your app (i.e. resource owner password credentials grant), or if you care little about user approval (i.e. client credentials grant). The catch is that your unilateral opinions are insufficient: the client and service provider need to be in agreement about whether these are okay to use.

And, as is often the case with "kitchen sink"-type specs, these other usage modes muddy the waters around the safer and saner usage modes, so much of the current advice on OAuth2 focuses on dissuading their use.

[1] https://tools.ietf.org/html/rfc6749#section-2 [2] https://tools.ietf.org/html/rfc7591

Much of the deployment of OAuth2 was a shitshow, because early on, there was a huge debate about OAuth1 vs OAuth2, and the concepts and terminology used in the OAuth2 spec exceeded the mental load of people who were simply looking for a quickstart to some API. Docs by various providers either adopted the OAuth2 terminology wholesale without sufficiently explaining the new concepts and the best practices, or they simplified the client registration to just a few fields and offered no guidance as to make use of them in your app.

The spec has been clear from the start that there are clients that can protect their secrets, and ones that can't [1]. Here's a choice quote: "A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted." Unfortunately, much of the rest of the spec is a bit like a playing puzzle, where reading it in one sitting doesn't actually build your understanding, and you have to constantly cross-reference various sections to construct a complete picture of the process the spec is trying to set.

It look a long time for people's familiarity with the spec to grow, and for providers and clients to improve in quality and adherence to the ideas and text of the spec.

[1] https://tools.ietf.org/html/rfc6749#section-2.1

In this situation, their guidance says to embed the secret, because in this context it's obviously not a secret. Here's the current page [1]; here's the earliest Archive.org snapshot of its one-earlier predecessor page from 2015 [2] -- the advice has been consistent.

[1] https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developer...

Lake Agassiz and Lake Missoula were glacier-dammed lakes that periodically overflowed the lowest sill of their basins to cause massive floods. Lake Agassiz is thought to be responsible for the deeply incised Minnesota River valley.

The shifting of glaciers and the ice sheet altered the effective relief of the basins over time, so simulating these lakes today takes a lot of work.

In the Great Basin, away from glaciers, Lake Bonneville and Lake Lahontan were the largest lakes that formed during a colder, wetter time, as endorheic valleys filled with water and repeatedly overflowed the lowest sill of their basins. Lake Bonneville is thought to have overflowed the outer edge of Great Basin itself at Red Rock Pass near Downey, Idaho; eroding the gap and releasing a huge flood into the Snake River basin.

Because a moving ice sheet wasn't a factor in their case, DEM shading can be used to approximate their overflows. This doesn't account for isostatic rebound or tilt in terrain, but gives a visually enlightening approximation, and lets one interactively explore how these outflows may have worked.

One can shade a topo map of the Great Basin at 4785 feet -- today's elevation of Red Rock Pass -- to approximate how Lake Bonneville's floods may have worked. Or, shade at these key sill elevations, in feet, to see how Lake Lahontan may have outgrown one valley after another: 3878, 3933, 3976, 4154, 4180, 4301, 4386.

Example with Caltopo at 3976 feet: https://caltopo.com/map.html#ll=40.28729,-118.02612&z=8&b=t&...

The ultimate, yet-to-be-realized killer app of a tablet would be to act as large drawing, editing, and writing surface in augmented reality -- and a cutaway-plane viewer.

Currently, it's mostly used (1) to consume content, (2) as a large touchscreen input device for skeuomorphic apps, and (3) as a drawing tablet.

While they have competent infrastructure, an IaaS offering needs a platform whose capabilities are more complex than one where you're running only first-party applications. And even if they spent the time and effort, they'd be entering a commoditified, crowded field. All the big players can run servers, the value-add is from SaaS and/or surrounding PaaS, the latter of which they'd have to build from scratch.

Their previous forays into PaaS, done at a time when Twitter was also in this space, have faltered. And Facebook's pre-existing services are too far up the stack to be relevant to any IaaS ambition.

I doubt the 'trust issues' contribute significantly in Facebook's decision to not offer this, but I agree they'd be a factor for potential customers once the offering came to be. Facebook's branding is odd in that they've doubled down on the Facebook brand despite acquiring services that flourished in part for being "not Facebook". They seem resistant to rebrand into a holding company, and their choice supports the view that the company's tech mission is to remain tightly coupled with their flagship social network.

> I don't suppose it will persuade you that String (and many other classes) are in the Java.lang package.

From the prior source [1], immediately below the previously-quoted text:

"Trial Exhibit 980, The Java Application Programming Interface, Volume 1, is a book that covers four packages and refers to them as the "core packages." According to the back cover of the book, these four packages "are the foundation of the Java language. These libraries include java.lang, java.io, java.util, and java.net. These are the general purpose libraries fundamental to every Java program."

[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...

IBM sued Corona Data Systems, and Corona settled [1].

IBM sued Handwell Corporation, and Handwell settled [1].

IBM sued Eagle Computer Inc., and Eagle settled [2].

[1] https://books.google.com/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=P... [2] https://www.nytimes.com/1984/02/22/business/eagle-ibm-settle...

Here's some additional context in from a lower court: Oracle Am., Inc. v. Google Inc., No. C 10-03561 WHA (N.D. Cal. Jun. 8, 2016) [1]:

"Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 "necessary" classes are mixed with "unnecessary" ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 "necessary" classes given that the Java programming language itself was free and open to use without a license"

"That the 62 "necessary" classes reside without any identification as such within the Java API library (rather than reside within the programming language) supports Google's contention that the Java API library is simply an extension of the programming language itself and helps explain why some view the Java API declarations as free and open for use as the programming language itself. At least to the extent of the 62 "necessary" classes, Oracle agrees."

[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...

In 886 F.3d 1179 (2018) [1][2], the Fed. Cir. noted that:

"62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise the language itself will fail."

"On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code — 11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use."

[1] https://scholar.google.com/scholar_case?case=107451649356761... [2] https://www.leagle.com/decision/infco20180327178

Instead, once your product grows popular enough, they'll just offer a managed, hosted service with a compatible API.

The official avif github [1] references Kagami/avif.js [2]. It's intended as a server-side component to be installed, and uses service workers to on-the-fly repack AVIF images as AV1 videos. The code is licensed CC0, and is easy to read, so you can tweak it to your needs.

If the browser can't natively decode AV1 videos, it calls dav1d.js [3] to decode, which is a webassembly port of dav1d [4].

[1] https://github.com/AOMediaCodec/av1-avif/wiki [2] https://github.com/Kagami/avif.js [3] https://github.com/Kagami/dav1d.js [4] https://code.videolan.org/videolan/dav1d

I am not a lawyer, and I realize there's a fine line between genuine concern and speading FUD, but in the spring of 2019 I looked into the patent situation around the HEIF container itself [1] -- the container upon which AVIF builds -- and skimmed through the 5 US patents I found, which cover some techniques that can be used in the format.

Most of them can probably be avoided for the purposes of an AVIF file, but patent US20160232939A1 [2] in my reading seems to be about in-container signalling to express relationships between a "static media item" and "one or more entities" that together "form a group", and "indicating, in the file, a grouping type for the group". The patent appears to be written in a way to allow this definition to encompass, say, a thumbnail and a bunch of frames thereafter, or, say a master image and a set of pictures derived from it, or alternate camera angles of the same thing. Some of these techniques sound like stuff we've seen before, but as is common in patents, the precise wording of claims is often key, and this is where patent lawyers come in.

A thorough look of the AVIF specification [3] and the patents registered with the MPEG LA about this format [1] is likely wise before any widespread deployment that makes use of advanced features of the HEIF container; using it to hold exactly 1 'one-layer' still-image is probably fine.

Additionally, in my reading [5], the HEIF reference software released by Nokia [4] includes a patent grant for non-commercial evaluation, testing and academic research only.

[1] https://news.ycombinator.com/item?id=19874321 [2] https://patents.google.com/patent/US20160232939A1/ [3] https://aomediacodec.github.io/av1-avif/ [4] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT [5] https://news.ycombinator.com/item?id=19874368

From English Wikipedia article "Advanced Video Coding", with cited sources:

"The commercial use of patented H.264 technologies requires the payment of royalties to MPEG LA and other patent owners. MPEG LA has allowed the free use of H.264 technologies for streaming Internet video that is free to end users, and Cisco Systems pays royalties to MPEG LA on behalf of the users of binaries for its open source H.264 encoder."

(...)

"On August 26, 2010, MPEG LA announced that royalties won't be charged for H.264 encoded Internet video that is free to end users.[74] All other royalties remain in place, such as royalties for products that decode and encode H.264 video as well as to operators of free television and subscription channels.[75] The license terms are updated in 5-year blocks.[76]"

[74] "MPEG LA's AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License" (PDF). MPEG LA. August 26, 2010. Retrieved August 26, 2010. http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachme... [75] Hachman, Mark (August 26, 2010). "MPEG LA Cuts Royalties from Free Web Video, Forever". pcmag.com. Retrieved August 26, 2010. https://www.pcmag.com/article2/0,2817,2368359,00.asp [76] "AVC FAQ". MPEG LA. August 1, 2002. Retrieved May 17, 2010. http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx