brenns10

My understanding (and take this with a grain of salt, I don't have sources) is that after the Norman conquest in 1066, the original English language was the lower class language and the Latin/French language of the conquerors became the upper class language. So the words which came to English through French/Latin tended to be considered high class, and the words from older English were considered lower class, rougher, and maybe in some cases more profane. A prime example might be beef vs cow: both referring to the same animal, but the higher class word deriving from French has become the culinary term whereas cow remains the term when speaking of the animal. (That I do have a source for: https://en.m.wikipedia.org/wiki/Beef#Etymology)

I think that's why some of the Anglish stuff (or Anglo Saxon class?) might come off as rougher, more basic, simpler, or more profane. It's really interesting (but also really sad) how nearly 1000 years can go by, yet a language can still carry the scars of oppression.

Anyway, that's just my thought, I'm no linguist or historian, so don't take my word for it.

I think it comes down to development cost. A lot of suburbs are developed by a single housing developer, and they essentially have a "theme" with similar styles and just a few floor plans to choose from. So some suburbs end up looking very cookie cutter. They also do things like clear all the old trees out prior to developing the land, which is cheaper and easier, but can create a very desolate environment to live in.

There are plenty of suburbs that aren't this way though, especially older ones.

> Or if someone is about to sign up to a Mastodon instance, it gently points out that this isn't really Twitter, and that the server administrator will probably read your private messages.

If you want the server administrator to definitely read your private messages, there's always Twitter! :P

Nope, it's not a technical reason. Zoning laws typically prevent you from building structures near the edge of your lot in the suburbs. They also mandate excessive amounts of space to store automobiles, and absurd setbacks from the street.

I'm not convinced you understood the comment you replied to, which doesn't suggest placing a public park in somebody's yard. It suggests that people are clinging to their yard when they could instead have a housing option which doesn't have a private dedicated yard, but does have a much larger and nicer public park nearby which serves that need for green space.

And honestly, if a person wants to make a little public park in their yard... I don't see what the issue is with that? But yeah, that's not what was suggested in the slightest.

We can have both, can't we? Obviously I don't like cul-de-sacs personally, but nowhere in my comment did I suggest banning them. The phrase you quoted was just a turn of phrase as I described my preferred style of land use which is currently illegal in most zoning laws. Right now.

It's kind of funny that your reaction to my comment is "he wants to take away the cul-de-sac" when all I'm asking is if we can get zoning for a decent alternative. I'm not asking to replace all the suburbs with this style of zoning, but especially as you get to areas with high unmet housing demand, zoning needs to be reconsidered.

It's important to be very clear: you're misrepresenting the options!

It's not a choice between suburbia and Manhattan. It's a choice between exclusionary, backwards suburban zoning (which is subsidized by denser development due to the increased cost of utilities for sprawling development), and literally any more sane option. Let people build duplexes, corner stores, local markets, and get rid of the cul de sacs. That's literally the core of the "density" people are talking about. Not Manhattan style high rises.

Saying that people (really any group, but millenials here) prefer suburbia because that's what you see them currently buying on the housing market, is ignoring the fact that the available housing stock probably doesn't match up to their preferences! Plenty of people are buying the "lesser of two evils" rather than their dream home. Plenty of people would choose something within walking distance of a decent park and grocery, if they had that option. But America, despite being built on the train and the pedestrian, has been rebuilt on the automobile and the cul-de-sac with single family home zoning. So people are buying what is available, even if it's not what they want.

If you doubt what I'm saying, check the prices of homes in prewar "streetcar suburbs" which are denser, but still have small yards, detached houses, and yet are near small commercial uses too. Plenty of people want to buy these and the prices have skyrocketed: it's illegal to build them now, so the supply is limited.

It's a strawman to compare detached suburban housing to the densest housing options on the planet. If you do that, it's only fair to compare it against cabins without utilities, off road and miles away from the nearest grocery. Very, very few of the "majority of Americans" want to live in that.

So, be honest and just compare suburban sprawl against, well, normal development where people can build town houses, duplexes, small apartment buildings, and of course small stores and restaurants. THAT is the density that the majority of people are talking about. Not high rises in ultra dense urban cores. I think more Americans than you think would like to be walking distance from a decent grocery store, bar, and breakfast place. I enjoy it!

I appreciate the concern for new developers, but I really don't think it's a good solution to have every project readme describe pip, poetry, pipenv, and whatever other new hotness there is in the package management world. There's a reason that all the readmes describe pip installation: it's the lowest common denominator, present with every standard python install, and along with virtualenv (also standard) it can do most of the requirements for package management.

I think to help new developers, we could encourage documentation to briefly point to the official PyPA documents on the variety of options available. It would be better to focus on making that more accessible, rather trying to throw the burden onto package maintainers to describe using their package with every new tool.

https://packaging.python.org/en/latest/key_projects/

You could instead drive at or below posted speed limits, and stop at traffic signals. Then you wouldn't have to worry about this "dystopia"! And the result is that you'd be a safer driver too.

This is ridiculous whataboutism. We're not discussing robocop sending you to jail for dropping a banana peel. It's simply automatic enforcement of safety rules for operating your licensed, registered, private machinery in public spaces.

It's not dystopian, but it raises the standard of evidence beyond what is feasible to support. With simple limits, you can say "I clocked you at 80 on a 65mph road" and that's evidence enough. You'd need far more evidence and deliberation to enforce the rule "you went faster than a reasonable person should".

Yeah, it was decriminalized because jaywalking was a crime invented by the auto industry and there's no real harm in it, provided that a person crosses a street when it is safe to do so (this is part of the new law, it's still illegal to cross when you cause a risk of crash).

On the other hand, traffic rules protect public safety. Even and automated enforcement (provided that there's no entrapment for revenue, something that is dangerous and does happen with, e.g. red light cameras) causes people to have safer driving habits. After all, driving is not a right, it's a privilege to operate heavy, dangerous machinery in public. Drivers should be held to a high standard of safety.

> Pretty much any effort to constantly monitor everyone's behavior at all times is dystopian, yeah.

You say "at all times" but like I said, this surveillance is limited to the times when you are operating your privately owned heavy machinery on public roads (which have posted signs regarding aircraft).

> The income from fines is the real reason it's done.

The article even explicitly says that the economics of aircraft doesn't work out for tickets. It's not about revenue, nor evil gov't surveillance. It's about public safety.

True, I didn't mean to imply that race was the only factor for unfair enforcement. Just one well-documented example. All the more reason not to add more subjective criteria for enforcement.

There's no alternative here. You're asking for a law where a driver gets to interpret the situation and decide whether a traffic law should apply to them or not. That's just unenforceable, imagine trivial court cases hinging on whether a "reasonable person" would drive a certain speed. Plus, most drivers think they're a better and safer driver than they really are. Do you really trust them to correctly assess the risk, not just to themselves but to others? I certainly don't.

These rules have to be black and white! Do triple digit (mph) speeds on a highway? Get an expensive ticket, even if the highway wasn't busy.

In this case you are operating your licensed, registered, several thousand lb machinery on roads subsidized and maintained by public money, at great risk to other road users (and yourself). Is it so dystopian that there's the chance you'd be monitored for the purpose of enforcing safety regulations?

Leaving hazy judgement calls up to the police for enforcement, at least in the US, has not fared particularly well for non-white people. See, for example, the history of enforcement of "jaywalking", a "crime" which was recently decriminalized in California for precisely that reason. So I wouldn't advocate for a system where we just "let police officers make that call" regarding whether a driver is going at a safe speed. At least not in the US.

And "design speed" may be an interesting or useful thing to think about for roads that are far away from houses or business, like highways. But if you're near those things then it suddenly matters a lot less whether the speed is safe for the driver, and a lot more whether it's safe for the other important road users: pedestrians and bicyclists/other micro-mobility users. In those cases, speed limits absolutely make sense. And bizarrely, at least in the bay area, it seems like those are areas where speed enforcement (and other traffic enforcement) are practically non-existent.

So I have to disagree. I know you're talking about highways, but even there I'd rather have something closer to an objective standard being enforced, rather than the simple will of the police.

You may want to try xxd -r. https://linux.die.net/man/1/xxd

Of course, if you're just looking for a fun programming exercise, then don't let me stop you :)

I'm not a fan of RMS, but as you noted, his blurb in the talk wasn't "Javascript the language is not free", or even "Javascript the ecosystem is not free", it's about the privacy invading factor of JS in a modern web browser. Since, as you said, software can be free and still invade your privacy.

He just doesn't want this GNU project to include support for a language whose primary purpose seems to be invading privacy -- even if it has a lot of great secondary purposes and a good open source ecosystem. Given that the GNU/FSF projects are all about advocacy in the area of software freedom and privacy, it seems like a reasonable perspective to have. Yeah, RMS definitely takes things to an extreme, but I don't see the "JS is implicitly evil" thing you're calling out, just refusing to appear to endorse or support something that goes against his principles.

And of course ironically enough those very principles mean he (should be...) perfectly happy with the emacs-ng fork, since that's part of the freedom he's advocating for.

I also disagree with this article's approach, but it seems pretty disingenuous to say that they don't understand terminal input because they didn't mention readline. After all, this is a blog post on the site for a terminal implementation. They'd have to be unbelievably ignorant to not be aware of the role of readline here.

They're not writing a technical deep dive, they're presenting their vision for a different approach. I think that vision is flawed but I'm not going to grade them on how deep they get into implementation details.

A lot to be said about this - setting aside the privacy/login/pricing stuff, I think the problems and solutions here are vastly overstated.

Yeah, terminal input is odd at times. Doubly so if your main prior experience is entering text into HTML textareas. There's a learning curve, but there's a benefit to tackling that curve. For one, you get readline editing, which is _far_ more powerful than the textarea comparison, and it's customizable. For another, if you need to use your editor to manage a larger command, you have that exact option (see Ctrl-X Ctrl-E in bash/readline). That editor can be vim, or it could be your pimped out VSCode with Copilot. Bash doesn't care.

When you think about it, that's a good 70% of the article's complaints resolved. Trouble navigating through lines of command input? Learn your readline keybindings, or just pop it open in your editor of choice, which also grants you syntax highlighting and whatever else.

The other 30% of what article proposes are pretty decent ideas. Why _isn't_ there a way to hover over a command and see a snippet from its manual page, or to hover over a command-line flag or option, and see the data from the manual page? We have bash-completion which can provide us command-specific completion, what about docs? Many new features can be added to the current architecture. For example, OSC 52 allows terminal apps to send data to the clipboard so long as the terminal emulator supports it. I don't see why similar extensions couldn't enable applications to annotate text with documentation, etc. But that doesn't require the terminal to take over all the line editing: it's just incremental improvement to the current system.

And that's where I think this article and approach are wrong. Maybe it works with the user's shell, but what about Python? GDB? Or the myriad other command line tools I use on a daily basis? As it is now, my terminal is responsible for being the best "terminal emulator" possible. It handles input, draws to my screen, and does it fast. It doesn't need to concern itself with supporting GDB: it is a terminal, and that's that. I'd rather not see these layers get smooshed. Let's focus on improving the current system so that GDB, readline, and the other pieces of the puzzle can incrementally improve the situation.

Thanks! All good clarifications. You're definitely right on all counts, and it was more than a bit naive of me to suggest that language/library authors "simply" have two production grade regex implementations :)

>> (And if you are using them, then I'd argue you're shoving a bit too much logic into a regex, but that's beside the point).

> This kind of ignores the fact that regexes are often the interface to something else.

I will definitely admit to using the occasional assertion or backreference in grep or sed from time to time, so you make a good point about local tools too. I suppose I was thinking more in terms of programming APIs when I said this, and so keeping the standard library FSM-based would still apply here. I'd imagine that special-purpose text munging tools which care that much, will likely have their own engines anyway.

Thanks also for your work on the regex crate. I'm still dipping my toes into Rust but I'm glad to know there's an FSM-based default regex library!

It really feels like they buried the lede here, as almost all discussions about catastrophic backtracking seem to do. Here's the second-to-last paragraph:

> Alternatively you could switch to a regular expression engine that doesn’t exhibit this kind of behaviour. RE2 is an excellent library that uses a finite automata approach to avoid this type of catastrophic backtracking. Using this library on the same 32 character input reduces the running time from 12 minutes to basically instant. The downside being that RE2 doesn’t support all the functionality of the builtin re package.

Perl Compatible Regular Expressions (the flavor used by most engines, including Python's) _require_ this exponential worst-case behavior (using an implementation called backtracking). But the theory behind regex does not require this, and if you eliminate just a couple (infrequently used) features of PCRE, you can have a regex engine that runs in linear time (with respect to the size of the input string). See [2], this is by the authors of RE2. The features which are incompatible with this sort of implementation are:

1. Lookahead assertions. 2. Backreferences to matched groups.

If you don't know what these are, or you rarely ever use them, then you really have no business using this kind of regex engine. (And if you are using them, then I'd argue you're shoving a bit too much logic into a regex, but that's beside the point). Nonetheless, every popular programming language (except Go[1]) has included an exponential backtracking regex implementation in their standard library, and exposed the entire industry to this stupidity, all for a few backreferences and lookahead assertions.

What's especially crazy is this: it's easy for a regex engine to detect the use of these constructs, because it has to parse the regex anyway! So it's feasible for the engine to optimistically try to use an efficient implementation, and only fall back to using a backtracking implementation when you're actually using these features. This is what the Python re2 module[3] does, it uses RE2 by default and supports falling back to the backtracking implementation if necessary.

Instead, we're stuck reading the same postmortem every few years describing how "catastrophic backtracking" ruined another company/person's day, when the problem has been solved for decades, and language/library creators have just failed to include that solution.

[1]: Rob Pike invented, or at least popularized, the algorithm used by RE2. He was also involved in the creation of Go, as was Russ Cox[2]. [2]: https://swtch.com/~rsc/regexp/ [3]: https://pypi.org/project/re2/

This is an excellent description of a false sharing perfoance issue, and I wouldn't envy the work involved in tracking that code down through the JVM. These sorts of issues are common inside the OS kernel itself. Kernels are managing lots of shared resources, and as you add more CPUs, these sorts of issues emerge as bottlenecks. They're enough of a problem that the perf tool recently got a new sub-command, "perf c2c", which tries to help identify false sharing (and other cache ping-ponging) issues much quicker.

If you're interested in learning more about this class of issues and the new tool, there was an excellent talk at LPC 2022 by Arnaldo Carvalho de Melo. And as luck would have it, the videos just came out, so I can link it here. In my opinion it was one of the best talks of the conference.

https://youtu.be/A23UopXKq6E

As an update, Google's "warning level" seems to have dropped to Yellow from Red: https://transparencyreport.google.com/safe-browsing/search?u...

I still see an exclamation mark in mobile Chrome, but it looks like the big scary red interstitial is gone from most browsers I've seen. Perhaps it was enough different people reporting false positive? Or maybe a re-scan or manual action. Unclear but it's appreciated. Wish there was more transparency (ironic given the "transparencyreport" subdomain that URL is hosted at).

Yeah it's probably an oversight, but that oversight feels particularly irresponsible given that it completely blocks the ability to access web sites (the primary function of a web browser) based on a third-party block list which can't be disabled.

I don't know, I got that exact error and searched the settings. I couldn't find that preference either.

Hi folks, my Mastodon server is now blocked as a "deceptive site," likely because its login pages are similar to other Mastodon servers. To a machine learning or rule-based system, I could see how that seems deceptive. But I'm now stuck in a several days to several weeks long wait for manual review. And of course there's no guarantee that manual review will result in a correct decision.

Meanwhile, it's truly incredible how fully my site is now blocked off from the world. Firefox Android won't even let me access it, while Chrome hides the click-through underneath the "details" button. My friends who use the site are understandably concerned, but there's not much I can do. It's crazy how a false positive in one centralized system can impact my little piece of the fediverse.

I agree with your perspective - for me Signal is yet another (more secure) internet messaging app on my phone, and I'm happy that way. I wouldn't want it to have anything to do with SMS, no more than I want FB messenger to start handling my SMS (which it does offer at installation time). Plus, having used Signal since the TextSecure days, I saw the SMS feature the same way the announcement seems to characterize it: as old tech debt waiting to get dropped. After all, I don't think Signal for iOS ever had SMS ability.

And to your main point, I hadn't even considered before seeing this comment thread that anybody felt differently, let alone so strongly. Really illustrates how differently people think about the same app.

This question came up in the discussion at the conference. There are several reasons:

1. The format specifiers for those types differ from the ones currently in use for the kernel. Nobody uses or wants to use PRId64 and PRIu64. If they did, they'd need to change thousands of occurrences (which is admittedly not too hard with tools like Coccinelle).

2. The stdint.h types are just typedefs (it's not like the compiler understands them intrinsically). And they're defined in terms of short, int, long, etc. The sizes of these are platform and compiler dependent. On the other hand, the Linux kernel tells the compiler "you must make long 64 bits if you are a 64 bit system" which may conflict with the defaults and throw those types out of whack. (at least, that's how I interpreted one of the points in the room, I could be wrong here)

3. Kernel is already using u32/s32, it's a smaller and easier change to go to u32/i32 in Rust style. People tend to find the stdint.h names to be verbose.

4. stdint.h brings in additional headers. I'm not sure if that's a problem or how - maybe in the Linux uapi headers?

There seemed to be general concensus in the room that stdint.h wasn't used for good reasons, so if these don't sound right, it's probably because I misinterpreted them.