hlandau

I have no idea why I would want a window in a bedroom (aside from as a fire exit). It seems more likely to be a nuisance.

This article and the underlying politics seems to be confused because it's confusing a bedroom and a living space. For college dorms obviously that's likely to be the same thing. But the problem here is arising from not having windows in a living space (e.g. where someone studies), not a bedroom.

If this proposed regulation (no comment on if it's a good idea) were to make any sense it should be saying "areas of an apartment where people are likely to spend a lot of time not sleeping should have a window", not areas intended for sleeping. If the apartment is one room those might be the same thing, of course. If I had an apartment with one bedroom and one other room, I'd rather have the window in the other room.

Still nice icons. Love the clarity and detailed shading of them at the pixel level, which is not something we see today with "flat" vector design.

It is kind of amusing how the printer icons when I come to think about it are actually visually referencing 10BASE2/10BASE5.

Case is only available in black?

Wish they wouldn't put that hideous logo on it.

I've heard claims that the keycap shapes have decayed as the original injection moulding moulds have worn. But judging by comments above it sounds like they have resolved that.

Audio keys feel like a necessity for me nowadays. The Ducky one3 I use puts them where the LEDs usually go and I feel that works really well. There's also existing Model Ms but lack of Super keys is a total dealbreaker for me.

So how am I supposed to put such a script in $PATH? e.g. if I hypothetically want to make a replacement for say 'ls', what am I supposed to do, force people to type 'ls.mjs' rather than 'ls'?

I've very rarely seen, say, image viewers which can't handle a JPEG with a .png extension or vice versa, but they're badly designed. Most handle this from the file magic automatically. Keying on extension is definitely an antipattern IMO.

I don't see people naming C++ files .c++03, .c++11, .c++17. I don't see people naming Perl files .pl-strict-mode.

Yes, it's normal for people to use file extensions, but having programs impose forced usage and semantics to them is a crutch and a sign of bad design.

How am I supposed to put a script written using this tool in $PATH?

This bad design seems to be a thing in the TS/JS ecosystem now. At least some language ecosystems (Deno? Not sure.) seem to be encouraging people to do 'import ".../Foo.ts"'. Which is abysmal: Firstly these are URLs, yet file extensions are against web principles and good URL design. Secondly they couple a consumer of a module to what language the module was written in and expose this as part of an API, which is terrible design.

>Write your scripts in a file with an .mjs extension in order to use await at the top level. If you prefer the .js extension, wrap your scripts in something like void async function () {...}().

Shebang scripts shouldn't have a file extension in the first place, so requiring one here is a dealbreaker. And having the file extension be used to switch between two different incompatible source formats is really a terrible design.

More precisely - it suggests one. Just like for TCP (see the myriad number of algorithms available for Linux's TCP stack) you can choose whatever congestion control strategy you want.

A bit surprised to see a common MCU used here rather than one designed for safety applications (e.g. TMS570). Is there any rationale to this?

If people are interested in knowing more about IBM i, we have a public IRC channel for discussing it with lots of knowledgeable people:

Liberachat IRC, ##ibmi

Feel free to drop by.

One of the most interesting things about IBM i/AS/400 is its use of hardware memory tagging. There is a secret set of extensions to the PowerPC ISA which allows you to associate a tag bit with every 16 bytes of memory. This is used to implement a capability-based model where valid pointers can't be forged.

I write some more about it here:

https://www.devever.net/~hl/ppcas

Interestingly this functionality is actually unlocked on the Raptor Talos II/Blackbird systems so you can play with it in full.

A serious mail provider would not block legitimate incoming email with massive amounts of collateral false positives.

A serious mail provider would care about ensuring that this does not happen and handle enquiries sent to the RFC-mandated address postmaster@ and respond promptly to such enquiries.

As much as possible, yes.

With something like QUIC "optimisation" breaks down into two areas: performance tuning in terms of algorithms, and tuning for throughput or latency in terms of how the protocol is used.

The first part is actually not the major issue, at least in our design everything is pretty efficient and designed to avoid unnecessary copying. Most of the optimisation I'm talking about above is not about things like CPU usage but things like tuning loss detection, congestion control and how to schedule different types of data into different packets. In other words, a question of tuning to make more optimal decisions in terms of how to use the network, as opposed to reducing the execution time of some algorithm. These aren't QUIC specific issues but largely intrinsic to the process of developing a transport protocol implementation.

It is true that QUIC is intrinsically less efficient than say, TCP+TLS in terms of CPU load. There are various reasons for this, but one is that QUIC performs encryption per packet, whereas TLS performs encryption per TLS record, where one record can be larger than one packet (which is limited by the MTU). I believe there's some discussion ongoing on possible ways to improve on this.

There are also features which can be added to enhance performance, like UDP GSO, or extensions like the currently in development ACK frequency proposal.

Nothing intentional about it. I certainly wasn't expecting it to get wedged in the way it did.

It was back to functioning normally only a short time later in any case.

This doesn't pass the smell test at all. There are multiple redundant CDUs and I'm not aware of any reliability issues with their keyboards in the countless other aircraft models which use them. And I second everything @etskinner just said above.

It's 100% about programmers wanting to make everything software defined.

This is deeply interesting.

I've sometimes contemplated the possibility of doing things like this to guard against memory errors causing mis-entry to particularly critical control flow paths - this is certainly an example of that. But never heard of anyone actually trying to do this until now.

A "how to write rowhammer-resistant code" writeup would definitely be useful here - even if it is definitely something people cannot do for anything, I can certainly see cases where there is a case for it.

It sounds odd to me. I'm merely recollecting a news report from probably about 20 years ago, which is probably going to be hard to dig up. If it's another case of the press getting something totally wrong, that wouldn't be surprising.

Somewhat related, I just discovered that the Boeing 737MAX replaces the CDU keyboard in the cockpit with a touchscreen emulating the same keyboard.

https://www.gableseng.com/wp-content/uploads/2020/05/G7330-....

I am lost for words...

Do you mean the exterior door beeping (officially known as a "hustle alarm" in the rail industry - now you know)? There has been a wave of adapting or replacing train door controllers to comply with the latest disability regulations recently. But all motorised train doors that I know of in the UK have had a hustle alarm.

I don't much care for the new "compliant" controllers though, not least because the sounds they emanate are quite unpleasant and often much less nice than the ones emitted by the door systems they replaced. Older hustle alarms, etc. sounded like they were produced by something at least slightly polyphonic, whereas all of these new systems seem to produce all of their sounds via an ear-piercing piezo buzzer only.

Besides the hustle alarm there's the sound to notify you the doors can now be opened (often not present on older, non-compliant systems, but now seemingly deemed required). I was always fond of the sound the Class 365/465 Networker used for this - an actual mechanical bell, which produced a pleasant sound. Of course it's now been torn out and retrofitted with an awful piezoelectric tone of the most ear-violating variety. It feels like nobody even tried to make these sounds pleasant, and probably went with a piezo buzzer rather than a mechanical bell because it costs less, and what hardware designer even knows how to integrate a mechanical bell these days?

The closest to not having a hustle alarm I'm aware of in the UK is for London Underground and DLR stock, which basically starts to play the hustle alarm at the same time as the doors close, making it a bit of a token affair.

Those interested in this sort of thing might be interested in this TfL report which actually studied in minute detail whether they should change the delay on the doors closing after the warning sounds. I encountered this once and was fascinated by the details. https://assets.publishing.service.gov.uk/government/uploads/...

BTW, the applicable safety requirements standard for power-operated passenger train doors is GM/RT2473 (or its predecessor on older rolling stock, GO/OTS300). Don't ask me how I know this...

The microcontroller obsession is real. As is the desire to do everything via software and not mechanically - see touchscreens in cars. I'm pretty sure it's because as developers, we're addicted to the notion of making everything software-defined so you can change everything later if needed. As a developer it's a thought process I understand well, but seems to increasingly lead to detrimental outcomes, like the extreme touchscreenisation of cars - awful from a safety perspective.

I am told that "superloos" (those automated self-cleaning toilets installed on the pavement) do have some kind of time limit and will play some kind of audial warning a few minutes before opening.

More concerning about those toilets are stories where people somehow managed to be inside the toilet when the self-cleaning process started (which involved the entire chamber being filled with liquid). Supposedly this would happen when someone used the toilet, but held the door open as they left so someone else could use it without paying. The toilet, then thinking it was empty, proceeds to unwittingly try and drown the "undeclared" occupant.

This is a fixable bug though. And no force of any kind was used here. As mentioned other trains use the same lever design, but with the lever being spring-returned, which doesn't exhibit this 'vulnerability'. It could also just be fixed in software by making the lock lever input to the microcontroller edge-triggered instead of level-triggered, so that if someone does actually do this it won't lead to a DoS.

(Author here.) I have seen videos (not on trains) of one hybrid - a power-operated round sliding door, but with a physical lock on it, that hooks onto the door frame. So that would be one option.

I think the current iteration is fine though - the replacement of the confusing "lock button" with the physical handle, even if emulated, is comprehensible to most, I would think. The "the door is now locked" voiceover also helps reassure people. (Most people are just trying to lock the door and not "fuzz test" the lock handle...)

Author of the OpenSSL QUIC stack here. Great writeup.

TBQH, I'm actually really pleased with these performance figures - we haven't had time yet to do this kind of profiling or make any optimisations. So what we're seeing here is the performance prior to any kind of concerted measurement or optimisation effort on our part. In that context I'm actually very pleasantly surprised at how close things are to existing, more mature implementations in some of these benchmarks. Of course there's now plenty of tuning and optimisation work to be done to close this gap.

I wonder what the firmware blob situation is with this. How much documentation is available for this SoC? It would be nice to have more platforms with fully open source firmware.

How am I supposed to use CURL to read it offline if it requires JS?

Won't work in links2 or lynx either.

I don't want to run the functions, I want to view them.

Also the functions execute on the server anyway (plus JavaScript isn't even the only supported language), so execution should also be possible without a browser having JavaScript enabled.

No, I'm referring to each Wikifunction page on the Wikifunctions site itself.

Still waiting for the Memristor...

Aerospace headsets... yeah, helicopter headsets might be the one case where you actually can find cable-powered active noise cancelling. But you're a long way out of the consumer sector at that point...

Those are battery powered, though. (And judging by the reviews not very good, and suspiciously cheap, so not really the same quality of product.)

I spent a LONG time looking for wired noise-cancelling headphones a year or two ago without success. By this I mean headphones where the noise-cancelling electronics can be powered over USB. It seemed obvious to me to design a pair of headphones with a USB audio interface which powered noise cancelling. But nope, doesn't exist.

Even worse all the wireless noise cancelling headphones I find, including high end ones, automatically turn off when you charge them. So you can't actually use them when they're charging. I'm certain companies do this due to some kind of liability paranoia about a battery igniting when someone's wearing them, but the result is that the entire product class seems to be literally designed to put an upper bound on how much you can use the product. I find this insane.

This post touches on a fairly common experience for me, which is assuming a kind of product must exist and then being surprised to find a complete gap in the market.

It seems quite common for a particular market to have come to "conceptualise" itself, or categorise itself, in a certain way that then becomes a prevailing set of assumptions of every company serving that market. This results in every product in a given market basically being the same and formed under the same set of assumptions, leading to a lack of meaningful choice.

Examples I've encountered:

- You can't get non-wireless (/non-battery-powered) noise cancelling headphones. Go on, try and find some.

- The market for presentation remote controls (that is, wireless clickers for advancing to the next slide) seems to be entirely conceptualised around proprietary 2.4GHz communication with one of those tiny USB dongles. The market for Bluetooth presentation remote controls seems to be tiny, and the ones that do support Bluetooth are hybrids which support both Bluetooth and a dongle. Also weirdly expensive.

- You can get Zigbee temperature/humidity sensors but getting Zigbee temperature/humidity/pressure sensors is seemingly much more niche, despite the existence of MEMS chips which can sense all of those. Zigbee temperature, humidity, pressure and CO2? Good luck.

Given how neat and useful Zigbee is as a technology I'm a bit surprised more isn't done with it and a more varied set of devices aren't available for it.