vetrom

While complying with our treaties as a nation is good and proper, those treaties remain subordinate to the Constitution. To the best of my knowledge, there is no verbiage in there that permits Congress to authorize a law for the mass collection of information, and the centralization thereof that is not directly pursuant to any of its enumerated powers.

This doesn't even touch the government, as a whole's, less than stellar record as it comes to protecting PII from improper disclosure. CTA, as written and implemented, creates a wide array of real and potential harms. It's bad law, as it stands.

You could de-peer/internet-death-penalty them, but, as is often the case, there is not alignment between the business objectives and network operator objectives.

There are a great many reasons the game is referred to as "Spreadsheets in Space", and decisions from the developers related to the ingame inflationary and deflationary mechanisms have had sea-change effects on its day-to-day gameplay meta over the years.

TBH most of the above is true for most any MMO where the scale of player activity can directly affect the game economy, EVE is just the most famous example.

Nifty project, this also reminds me of m68k.news which I think was on here a few years back. (source: https://github.com/ActionRetro/68k-news )

It's certainly an annoying future. I fully expect some sort of ASN-reputation map and service to become de rigeur in the next decade. Pretty sure heavier-duty SIEM/IPS systems already do that.

Email platforms are actually two platforms, composition, and delivery.

In the before times, I helped build and was a lead engineer on a team building a delivery platform from scratch, with very minor composition bolted on. (For a time reference, this was before HTML email was even common.)

Some of the lessons from then are very relevant still today. A big one that comes to my mind is 'idempotent' email isn't really possible, because SMTP has no 'send iff message-id has not been received' primitive. You can get to try-send-only-until-2.5.0-code, but even that can be non-trivial engineering. We went to a rather large degree of effort to do that ourselves, since repeat emails are a terrible signal, but I think thats only a marginal benefit to the larger operators.

Idempotent delivery even isn't a direct benefit to advertisers or most sending actors: Primarily, for the majority of the market, they don't really care about duplicated deliveries below some statistical model, since the costs are heavily externalized. Secondarily, since those parts of the industry depend on out-of-band read-indicators, engineering to improve delivery idempotentcy doesn't reflect into a market advantage.

Email's gotten prettier in the two decades since then, but its quality at every point in the stack I think has gotten worse. I routinely have to firewall whole ASNs because the bigger bulk operators (salesforce marketing cloud im looking at you) have no functional mechanism to call out particularly spammy customers, and thats after aggressive greylisting. Sure, the greylisting cuts out >95% of my spam, but the noise level on that last 5% is still horrendous. Forwarding with headers to abuse@ should be a universal paradigm but thats 99% a noop these days.

Given the lesser upside and relative difficulty of the delivery problem, it seems only natural that most of the effort in email platforms these days is in composition. Even if you want to work on the delivery half, with IP reputation, aggressive antispam, and the general enshittification of all things email, the barrier to entry is orders of magnitude higher than it was in 2000. I don't want to say its impossible, but I think you'll have a bad time if you're trying to do it anywhere that doesnt have enough size/inertia or money that email receiving operators choose to negotiate with you rather than preemptively block you.

> Sentry has never been GPL.

That was my mistake, my brain remembering wrong. https://github.com/getsentry/sentry/blob/9.1.2/LICENSE was its last open source license, MITish, right?

As for calling it "*source" and saying "oh we're not pretending its open source"? This is a point of opinion, but I think that's disingenuous marketing, at best.

Not one bit, I misspoke from memory there, sorry. FWIW I spent multiple years running Sentry for some fairly large orgs in the eras prior to Sentry's first relicensing. A large part of what got our teams interested in the product were the quality of engineering and the low risk of adoption.

In particular, not having to worry about some others' business model changing and increasing the risk of using the product, as well as the experience with Sentry being portable across many different companies and verticals.

When a midsize company drops what was previously an open source product, and turns it into something that shifts to an enterprise sales model, the value of that experience drops drastically. IMO that drop is the reduction of utility and value of that previous experience. It also creates a gap that is a real problem in making open source software sustainable at scale -- if no company can afford to take a successful OSS product and graduate it to a more structured and contractual environment, that creates a ceiling on how successful OSS software can be.

I appreciate that Sentry is (i think?) trying to create a real solution to that, but I think their basis for it is wrong. I have some of my own ideas on what a solution there would look like, but its something I'd really have to study more deeply as well I think.

I see your point about commit ratio, and that I admit is a correct view of the tangible contributions, but I also dont think those are what got Sentry its traction.

I will then ask, do you think Sentry would have been able to get enough of a mass of users to justify getting the VC funding it did if it weren't a MITish licensed product in its early years? How do you value the various libraries of user interaction, issue submission, and other market intangibles?

For a product developer, that is an external cost/value to you (the theoretical 'you', in this case), insomuch as there's no contractual obligations there and its not exactly clearly recorded in valuations and balance sheets, I believe. That openness and availability over time builds up a body of goodwill that I believe is critical to the success of a longterm opensource product.

As for Redis, enough people cared about the license change that valkey (https://valkey.io/blog/hello-world/) got stood up essentially immediately, which also got significant amount of developer traction. I notice that you dont mention them at all in your writing about Redis. Why is that?

Per previous discussions:

- https://news.ycombinator.com/item?id=38877059 (sentry FSL relicense)

   - in particular: https://news.ycombinator.com/item?id=38312686 (rugpull licensing still possible on future versions/contributions)

- https://news.ycombinator.com/item?id=38046537 (an aside about AGPL vs BUSL vs similar license schemes)

- Sentry's first relicense: https://news.ycombinator.com/item?id=21466967

Looking back to the first relicense in particular, the company effectively doing a rugpull on third party users/contributors, and the trend of companies trying to pretend they aren't doing exactly that sours me on basically any 'opencore'/required CLA project. I make rare exceptions for non-profits, but only those that are mature, well established, and not the sort of non-profit that puts most of their operation under a for-profit entity.

As woodruffw mentions, these implied-value-judgement labelings are really marketing terms designed to muddle the value and importance of what it means to be an open source product.

If it doesn't work for your business, fine, don't use an OSS license. But don't expect us to slurp up your peddling when you want to pretend its an OSS license, and don't act sad when you alienate swathes of your contributors.

*EDIT*: I misspoke, my brain had thought that old Sentry licenses were GPL, they were more MITish as seen in the LICENSE file in older releases of Sentry. My mistake :\

FWIW, if Sentry had stayed MIT or even moved to AGPL, I think they would have stopped much of their newer competition from even coming to market (I'm thinking of signoz, glitchtip, vs OTEL and its million integrations here.)

My position in 2019 was that much these decisions are being driven by the VC money, and I believe that is still true today. If it weren't, they could have chosen options that served the wider community better. (I also think that wider community and the accessibility of such is what got sentry much of its initial draw, but TBH im not sure how much that bears out in reality. I haven't studied deeply enough to have a good idea of the numbers there.)

This, in part, is why distributions like Debian go to the trouble they do to build everything from more-or-less isolated sourcecode artifacts.

Sure, its not always perfect, and getting say, blobless, is a challenge of its own, but no distro in their right mind for example, would ship arbitrary .o or ld.so objects in source packages.

Way back in my matriculation, I saw the same behavior but written in terms of CVS, even. As some other posters have written, CS, as it is purely taught, doesn't often touch on the realities of software engineering and delivery.

IMO, it should. An education without any relation to practical skills just makes it that much harder to leverage what you learn.

What have search engines got to do with vehicle data reporting privacy? I suppose there must be some connection, but how is it relevant to this concern and article?

That said, developing, and operating a search engine is no small lift. Brave did it by acquiring/acquihiring another company. While I suppose that's in the scale of the Mozilla Foundation's budget, I suspect it would be a bad move for them.

Primarily, in terms of politics and partnerships, and maybe the motivation of some of their staff to remain gainfully employed, I expect they have fairly strong incentives to stay out of the search market.

They prefer it for a number of reasons, for better or worse.

The big reasons I usually call out are:

- packages should be buildable without calling out to any network resources. (this is the primary reason Debian dh-make-golang disables 1.11 style gomod support)

- Debian specifically avoids vendored copies of code. This does create functionality and miantenance challenges, but it also produces a leaner installed code base. One again, for better or worse, this is a standing part of Debian package policy and warts from this particular choice stand out all over, not just golang. (newer Debian python, for example outright disables pip for non-venv python)

There are other nits and warts that become apparent, but I think those all waterfall out from the two points I've called out here.

(The Debian package policy in question: https://www.debian.org/doc/debian-policy/ch-source.html#embe...)

Lots of browsers avoid it for reasons, but isn't this the whole point of the OCSP(https://en.m.wikipedia.org/wiki/Online_Certificate_Status_Pr...) and OCSP stapling?

> Hell, they allow scripts for one-click product activation bypass to be hosted on GitHub.

On one hand, it's a potential revenue center -- I would not be one bit surprised if data collected from these repos gets fed to processes like BSA audit targeting.

On the other hand, repos like that can be useful as well for software preservation and the like.

You don't need government backdoors when os trust isnt user-trustable and you could chain whatever into a sesame backdoor: https://eprint.iacr.org/2021/626.pdf (for the tldr crowd; this explains a fairly glaring failure mode in signal's post-compromise security when any secondary devices are involved)

I am generally wary of anything that proposes to monetize the process of doing my core work.

I recognize that that attitude makes marketing and selling a product to developers difficult, though. If they changed from a CLA to a DCO I'd feel less uneasy about it, but but is that something their investors and business can permit?

You may have induced latency driven by window sizing/scaling/acknowledgement RTT as well.

If nothing else, technician-free battery replacement simplifies maintaining a personal chain of custody, and thus, longevity of the trustable life of a product.

Not a directly trust related issue, but an often conflated factor. (assuming you dont do something exceptionally silly like make the batteries have a serial interface and protocol that can be its own attack vector. Wait a sec...)

Not to keep running with thr joke, but:

- while a total lockdown on exposure control of your personal data is basically impossible, proactive choices do limit it shouldn't be dismissed out of hand

- a working knowledge and practice of bushcraft can be a useful skill, a fulfilling hobby, and can be practiced without feeding money to whatever the flavor of the week is

- conversely, if you do get into that, be prepared for profiteers in that field to push into your attention. Going all bushcrafty is no protection on its own.

IMO Gitea is fairly protected against a 'random' relicensing, as the project does not use a contributor licensing agreement.

While license and quality shenanigans can still happen, say if their technical oversight committee went bad, they cant do the same sort of rugpull done by projects that made contributors give all ownership interest to a single party.

GOGS (gitea's origin project) is still around and keeps moving at its own pace, as well.

nVim has interesting ideas, but it doesn't yet have the level of stability that I require in my daily driver text editor. I have colleagues that heavily use nVim and note that it crashes occasionally. While you can make pretty much anything crash, there's a watermark of bullet-resistance I expect, as it were.

Also... Why is this post flagged? Did someone merely dislike the title? it's a decent question IMO.

It is no longer a requirement, but there is a significant amount of amateur spectrum where CW (morse) is the preferred or only permitted modulation.

The expression is a bit different but this is literally a (minor) piece of worldbuilding in Daniel Suarez's 'Daemon' (2006).

Having an automated per-user publishing pipeline for packages is a non trivial endeavour.

These days you can get close with github-actions style pieplines and releases, but the PPA system has always been a more complete platform in terms of dependency management.

You can get close with some debian tooling (im a fan of sbuild), but it's some overhead to deal with.

They also benefited from a large ecosystem of third party contributors, whom were not (at least, visibly?) considered as stakeholders when Hashicorp implemented this license change.

I'm pretty sure no-one contributing to a product's ecosystem likes it when the previous agreements related to IP underpinning the ecosystem is rugpulled out from under them.

Theres VLIW/'preprediction'/some other technical name I forget for infrastructures which instead ask you to explicitly schedule instruction/data/branch prediction. If I remember, the two biggest examples I can think of were IA64 and Alpha. I wanna think HP-PA did the same but I'm not clear on that one.

For various reasons, all these infras eventually lost out in the market due to market pressure (and cost/watt/IPC, I guess).

Even before then, the sufficiently paranoid (but still bound to AWS for whatever reason) would track usage/steal/IO reporting along with best guesses for Amazon hardware expidenture and use that information to size instances to attempt to coincide with 1:1 node membership.

A VM nest in "big iron" isn't a special case. It's a context push with comparatively exhaustively defined costs, side effects, and implications.