If you want plain unassuming looking hardware get dedicated wifi access points and place them all over the building. There are plenty of those shaped liked big smoke detectors.

If you want single device there are also quite a few trash can shaped home routers.

Plenty of DIY projects used ATtiny2313 with V-USB. That's a pure software USB implementation bit banging the IO pins (not a USB stack on top of hardware USB support)+ your application logic squeezed into 2K of flash + 128 bytes of ram.

Chips like this are great for digital glue logic. Read a sensor, read a button press, blink some LEDs with simple state machine or control loop.

I am pretty sure that whatever contract streaming platform has with publishers has a some kind of date. It might be unpleasantly short (a year or month) making it look like a bad deal, but that's the point.

In current situation the "unknowable" date might be as short as 1 day. It's up to the good will of streaming service to warn ahead of time. Knowing what you get and the quantity of it is the most basic part of fair deal.

If a streaming service has only negotiated a 1 month license they shouldn't be allowed to re-license the content for longer period. If they want to offer longer deal they need to negotiate better license with publisher or take the risk on themselves by being prepared to give refund in the case of failure to deliver promised service. Telling that they guarantee only single year of service to provide doesn't prevent them from providing it longer.

If a travel agency rents a bus for a day, offering a 1 week trip around Europe would be considered a scam.

[1] https://consumerrights.wiki/w/Sony%27s_attempted_removal_of_...

Same thing here hardly anything common with hobbyist resin printers beside using some kind of UV curable resin. And as with other 3d printing technologies Stratasys is decade ahead in terms of research and commercialization sitting on all the relevant patents and selling expensive machines (sometimes as a result of acquisition).

Once the patents ran out maybe there will be more advancements and general availability. Although I expect much longer delay compared to FDM and SLA/DLP 3d printers. Inkjet printing on paper is already complicated and finicky enough, It's not something a hobbyist can make from scratch in a garage. Add a resin which will by design solidify when exposed to light potential destroying the inkjet nozzles, and doesn't necessarily behave as regular ink when attempting to spray it through inkjet head and you get the need for some serious investment to recreate the technology even with patents expired. The recent hobbyist 2d UV printers are step in this direction, but commercial/industrial UV printers have existed for quite a while. To me this suggests there is additional gap in patents/technological challenges between textured 2d UV printers, and full 3d UV inkjet printing.

In case of something like underground tunnels these problems are avoided by having hole big enough to fit the drilling machine as well as all the equipment and crew to reinforce the walls with concrete.

The fact that people have made a way to drill few hundred to few km using mechanical means is already an engineering marvel. In the context of everyday manufacturing beyond the hole depth to diameter ratio of 5:1 things already start to get more complicated. With more specialized techniques you might get 10:1 - 100:1. A bit easier for softer materials like wood or if you don't care about precision. But for deep underground drilling we are talking about ratio of thousands to 1.

It's not like they are not making tests at shorter depths. Once technology is sufficiently developed it might also trickle down to some shorter few km holes if geological conditions are right. Although probably never for something like few dozen meter water wells or making a hole in concrete at construction site. Not sure how well it works in soft dirt. Who knows about distant future, we now have relatively cheap desktop laser cutters, laser pointers, measuring equipment, microwave ovens, but those were not the initial products when developing those technologies. On the other hand some tech like wire EDM has remained niche manufacturing technology, even though modern electronics and software could allow making it much cheaper.

Having an icon of smartphone in a smartphone for the call app wouldn't be very helpful. And considering modern usage a smartphone doesn't even a have a strong association with calling.

> The inflexibility persisted and has arguably only become more aggravated in the 20th century

What about 21th century? Digital printing can overlap characters just fine. And modern fonts support context sensitive ligatures and glyph substitutions.

Second/third example those seemed to be caused by more by someone who doesn't understand the language copy pasting stuff.

PDF -> that's just PDF being bad. Text and text search in PDFs tends to mes up even or English.

> with unicode number U+0623, but one can also type أ, which is an alif and a high hamza, represented by unicode numbers U+0627 and U+0654.

That's what Unicode normalization and locale settings are for. Same thing applies to large fraction of latin based scripts other than English, anything which has letters with diacritic marks.

> for كثيره and كثيرة will in most cases yield different results

Similar thing in almost any non English language for example cafe and café or ABC and ⒶⒷⒸ. Although at least some systems handle it reasonably. Not sure how much it is heuristics based on large data (hard to scale across software), and how much it's good application of Unicode character decomposition/normal form tables. Which Arabic letters lack appropriate Unicode decomposition (and other) tables and what are the best practices of unicode normalization/decomposition/locale handling for search (applicable for all languages) are more interesting and actionable topics.

> Not even the simple idea of CJK has been implemented.

Many users of CJK language would argue that CJK unification was a mistake. If different languages prefer different forms of the glyph, they should better be separate characters. Having separate Chinese and Japanese fonts because CJK unified too much just introduces additional points of failure.

Many of traditional block cypher encryption modes do `cypher_text = plain_text ^ block_chypher_output` with the differences being what goes into block cypher input. This means that single bit flip in cypher text maps 1:1 to bit flip in corresponding decrypted block (and sometimes uncontrolled flips in next block). For malleability prevention full protocols would use MAC in addition to encryption. That's not very practical for memory encryption. Ability to use of various chaining modes is limited since you don't want to re encrypt whole ram when single byte changes or otherwise reduce parallelization of ram processing. Only traditional mode which doesn't degrade parallelization is counter mode, but that's fully susceptible to controlled bit flips. Maybe they can use chaining at cache line or cache block level.

This made me think. If the memory controller is already implementing encryption with limited chaining at block level. It wouldn't take much more additional resources to include hardware MAC as well, thus providing much stronger error detection (not correction) capability compared to typical ECC. The fact they aren't advertising it makes me think they aren't doing it, thus using some kind of counter mode variation and thus no extra bitflip protection.

Any extra cost would be mostly due to power consumption and testing that the feature works (which they probably don't do for consumer skews anyway). The area of silicon used by the feature is probably negligible, from the manufacturing cost perspective it's cheaper to avoid any unnecessary design differences between skews.

Code forges lead to the next reason -> they are making it open source (see the faq for why). If they want community collaboration it makes sense to prefer industry standard tooling. Organization internal consistency doesn't matter to external collaborators. Various Google projects with all their custom tooling are good example of what happens if this gets ignored. Every time I have to deal with depot_tools or repo it's a pain.

Third reason not to self host is that it's not quite production ready (see "Is lore production-ready?" in the FAQ). Can't be self hosting from day 0 and once you have a working setup you need better argument for switching just because you can. If lore was attempting to make a statement that it's a superior method of version control for regular source code it would be a different story.

In the picture at Renault website (section describing their next gen 2027 motors) you can clearly see the 2 slip rings on right side. That might be just a placeholder using their last gen motor, but I would expect that they would mention it if their next gen was brushless while the current one has brushes.

Brushless seems to be a thing that they have described as future work for at least 5 years but it's not there yet.

I don't think any of Qt default themes in last 10-15 years have looked anything close to that. With all those gradients and gray rectangular boxes it's more like a parody of early 2000s x11 theming and Flash based UI frameworks. My personal expectation when hearing QT style would be more like the builtin Fusion style.

If you ignore the central part with gradients, right side with square 3d boxes look a bit like classic win32 style (which would also be what QT used on windows by default) but you wouldn't normally end up with so many nested raised 3d boxes (or visible nested boxes in general). Buttons (and other clickable subcomponents) are raised, tabs are raised, but UI group elements have more of recessed border and you would use it sparingly. Often you would have just a separator line or empty space for grouping elements in flatter UI hierarchy.

Qt is GUI framwework for C++. How would having a bunch of C++ code containing barely any styling in training material help styling a website? Also the whole point is that it's a style that you don't recreate it hundred times it's what you get automatically by letting the GUI framework and theme engine do it's work. The modern Qt with Qt Quick/QML and it's flavor of CSS is closer to web development but those kind of Apps lack any kind of characteristic QT style since the authors are more likely to build the styling from scratch (resulting in one of those UIs with random image in background and hardly recognizable widgets) or based on builtin Qt versions of Google/Windows/Apple style guides. Wouldn't expect any modern QML based app to look like the obtained "Qt" style. In the traditional desktop apps based on QtWidgets, you can customize the style with css but the hard coded logic within the theming engine (implemented as native dll) is equally important for the look, not everything is is defined by css. You have to do either very little customization (minor styling for individual special elements maybe a color pallet swap) or override everything, otherwise it's easy to end up with ugly, broken result. Typical problems being Qt changing default base theme based on platform, theme engine switching to fallback rendering path once you override certain style properties.

Another important aspect of the classic desktop look which doesn't really translate well to websites is the set of widgets. Frameworks like Qt(widgets) provide reasonably wide range of widgets and you would use them as is. Unless you really needed it rarely would you create a widget from scratch or recreate what's already available. You wouldn't recreate a button, checkbox or a dropdown(combobox) using bunch of divs which can't be said about the modern web design. You might customize the behavior of builtin widget with subclassing or by combining multiple builtin widgets. The API for drawing custom widget from scratch is a pain and using it correctly to properly integrate with theme engine is even bigger one.

Every animation tool will provide consistency across frames of single animation, but functionality for aligning and managing transitions between pairs of different animations is less common and more in the territory of game development tools instead of animation drawing.

That's still something the game programmer linking animations together should be familiar with. You could still have artist use single frame size for all animations, but that means having gigantic square many times the width/height of character since you can have some animations which are stretched horizontally and some which are very tall. And if your workflow doesn't include good sprite packing, such gigantic frames can easily become impractical in terms of texture size. Having the game programmer define single anchor point per animation (assuming aligned frames within each animation) doesn't take much time at all. You wouldn't want to realign individual frames within each animation (that's part of artistic intent and artist should do at least that much), but even that would take order of magnitude less time than the process of drawing those frames. There are still times the programmer might have to go through each frame defining anchor point/hitbox, when artist picked a wrong config during export producing packed sprite sheet and there is no time to reexport it, or when dealing with animations that mix animated and software driven movement like large jumps.