lysdexic

joined 1 year ago
MODERATOR OF
[–] [email protected] 0 points 1 month ago* (last edited 1 month ago) (3 children)

Still no contracts?

In line with the release process for C++ standard specifications, where standards ship every 3 years but alternate between accepting new features and feature freeze releases, C++23 was the last release that was open to new features. This would mean C++26 is a feature freeze release following the new features introduced in C++23.

[–] [email protected] 3 points 1 month ago (1 children)

named arguments

Is this supposed to be a critical feature?

[–] [email protected] 1 points 1 month ago (3 children)

Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (...)

I don't know what you are talking about.

Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.

.NET does the exact same thing with it's class Microsoft.Net.Http.Headers.HeaderNames.

I can go on and on.

[–] [email protected] 6 points 1 month ago (5 children)

Bloating HTTP and its implementations for REST-specific use-cases

I have no idea what are you talking about. Setting a request/response header is not bloating HTTP. That's like claiming that setting a field in a response body is bloating JSON.

[–] [email protected] 3 points 1 month ago* (last edited 1 month ago) (2 children)

Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

Taken from https://datatracker.ietf.org/doc/html/rfc6648

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

I still work on software that extendively uses X- headers.

[–] [email protected] 1 points 1 month ago (1 children)

I don’t see why using submodules as a package manager should excuse their endless bugs.

I don't know what are these "endless bugs" you're talking about. Submodules might have a UX that's rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.

Do you actually have any specific, tangible issue with submodules? Even in the cases you're clearly and grossly misusing them

[–] [email protected] 6 points 1 month ago (1 children)

It's interesting that the internet is packed with search hits of complains that Cloudflare's DNS is slowing everything but Cloudflare representatives are quick to post followups pointing the finger everywhere else.

[–] [email protected] 5 points 1 month ago

Asking this question is like asking when was the last time you had to search through text.

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago) (3 children)

Aside from the obvious UX disaster, Git has some big issues:

I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.

What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.

Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.

[–] [email protected] 8 points 1 month ago

There are no hard set rules, and it depends on what uses you have for the build number.

Making it a monotonically increasing number helps with versioning because it's trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It's not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.

You sound like you're focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.

[–] [email protected] 2 points 2 months ago

Remembering ActiveX Controls, the Web’s Biggest Mistake:

Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?

[–] [email protected] 3 points 2 months ago* (last edited 2 months ago) (2 children)

Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn't be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

view more: ‹ prev next ›