Karliss

Some of the not quite 90 slopes seem to be due to arrows representing more of topological structure not necessarily accurate geometric representation. Could be elevators with doors on both sides, connect doors on opposite sides and you will get a bit of slope. Some of them might spiral stairways. The vertical spacing between floors is likely also exaggerated for clarity. Underground there might be larger gaps since the train tunnels need to go over each other under the rivers and what not, but there is no way 3 above ground floors (4f-2f) have empty gap 5x the ceiling height of individual floor.

1) Make an ambiguous text 2) Feed it to AI and see which of the 2 it picks 3) If it detects both repeat step 2 using minor adjustments or different AI model until AI responds with one of 2 message 4) Make a blog post claiming that AI chose dummy and other message was the real one

Scammers can also trick the victim into reversing the roles and telling password to scammer. Even banks ocassionaly get this wrong. I have had my bank call me and ask me to read numbers from number card. If a trained bank employee following a script designed by (hopefully) an expert cant get it right, the chance of elderly relative spotting mistakes in protocol is close to 0.

0 FLOPS those MCUs only support IMBC instructions. No hardware floating point, at least it has integer multiplication/division. My estimate is maybe 1-8Gflop total using software float. If you avoid float and design around fixed point, might do some interesting stuff.

It's a prisoners dillema. It might be best choice when viewed individually but when everyone does it, it's worse for everyone.

Don't buy one which looks like that if visuals are important for you. I already told that there are plenty of models which avoids this design and form factor. Do I have to spell out specific manufacturers and models?

Almost none of the Ubiquity stuff looks like that. Xiaomi has plenty of white/gray cylinders or boxes with rounded corners. TP-link has whole Deco series, Asus has ZenWifi series. Majority of MikroTik non rack mounted hardware also targets more neutral design.

You also have to consider who is the target audience for dedicated all in one wifi routers. Majority of regular people are fine with the WiFi that's builtin the modem provided by their ISP. Any serious commercial office will have the IT team to setup separate (rack mounted) router/switches and ceiling mounted access points that look like previously mentioned smoke alarms. People with large enough house to need multiple access points but aren't IT specialists willing to wire up Ethernet everywhere -> various product lines described as mesh routers. Like the trash can shaped TP link Deco series and similar from other manufacturers. If your house is not that big, nothing stops you to buy one of them and ignore the mesh functionality. That leaves people living in small enough house/apartment to be served by single router/switch/Wifi access point combo but for some reason not being satisfied what the ISP provides and also wanting multiple wired connections. Exclude the IT specialists willing to set up home lab and you are left with gamers (potentially impressed by black spider) and few others who have hopefully have enough rationality to place the router where it's not an eyesore or picking some of the previously mentioned stuff.

Another factor is move from antennas that are simple correctly size wire maybe with some spiral which easily fits in small rounded antenna to flat pcb antennas which encourage more rectangular design of the antenna housing and rest of the router. A lot of it is still partially just for the show, trying to give the impression "this one has more/bigger antennas must be better WiFi", but oversized partially empty plastic antenna housing were a thing even before current spider trend.

White slightly rounded 8 legged spider still looks like spider. Trash cans have a bunch of antennas but they hide them in larger volume. Dedicated access points have the advantage of being placed more predictably (near ceiling with little obstacles), they also have advantage of being distributed less work for each of them instead of single router covering whole house.

Wifi 5-7 happened, now operating at 3 different frequency ranges (2.4, 5 and 6Ghz) and using techniques like beam forming and MIMO. All those antennas need to go somewhere.

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.

1KB isn't so bad unless you are making something complicated or need large buffers. You can do quite a bit of nontrivial stuff with it. Years ago I made universal remote with ATtiny13 + external EEPROM for storing remote data. It has only 64 bytes of RAM, that's what I would call very tight. Was still able to program it in C, 1KB flash and number of pins were bigger limiting factor than ram.

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.

The prices are right there if you click "ordering & quality". $0.19-0.23 depending on exact variant at quantities of 1000 and up. $0.6 for 1-99 although that will likely vary a lot if you are buying through a distributor instead of directly.

Oftentimes that end date is not clearly knowable and can't be communicated explicitly

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.

Again? They already tried to pull that one a few years ago.

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

Calling it a resin printer is like calling a FDM printer and injection molding machines in the same category, both can melt ABS but the way they work and capabilities are completely different.

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.

For shorter holes traditional mechanical methods work just fine. If you are going to build a giant excavator you don't waste time making shovels for gardeners. The problem drilling deep into ground is that the power source on the surface of earth and drill bit deep underground are connected by long floppy noodle while the hole is getting crushed from the sides by bunch of elephants. It is difficult to transfer rotation from the motor/power source at the top to the boring head, and reinforce the walls to prevent them from collapsing, having whole thing heated to few hundred ℃ doesn't make it easier on hardware.

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.

I don't think it's much worse than having an icon of mobile phone from 90s with a grid of buttons and external antenna. Almost no one is using those either. And a featureless rectangle with rounded corners in the shape of modern smartphone doesn't make a good icon. The best you can do is rectangle with circle for pre iphone X style home button or more generic slots for speaker/microphone which still makes a bad icon and are going away.

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.

It can and has been done just not very practical. Having a dozen GB language model just to squeeze out few more percent on plaintext compression which already compresses well and is tiny in comparison of images or video is not worth it outside benchmarks. Even superior traditional conpression algorithms are often not used due to insufficient software support. Multigabyte decompressor as big as rest of your OS installation is not practical to distribute or standardize. It would also take a lot of memory at runtime for decompressing thus shadowing the efficiency gains in everyday use. Only if you have huge archival scale of data it might be worth the gains. But for long term archival fragile formats which depend on huge arbitrary extra knowledge isnt a good idea. I am not quite sure if ai based compression would make it more robust by allowing to fix corruption based on context or make it worse by having single bitflip produce completely opposite but still plausible looking text. At least with traditional compression its usually obvious when corruption causes gibberish. And then you have problem of versioning, you need to have exactly the same version of dozen GB model for decompression as was used for compression. Just one of them is questionable now imagine having to store few dozen of them. Most computers have code for supporting at least half a dozen compression formats, and many of those are parametrized allowing single algorithm to handle multiple varations of the compression scheme, and then many apps bundle their own copies of compression library.

The fact that the article was able to show correct version in regular text is pretty good indicator that if done correctly those are more or less solved problems. I don't disagree that there are probably plenty of times when those mistakes are repeated and solutions not used widely enough (more often for Arabic scripts than other languages), but even for 2017 it feels more like anecdotal examples of what can go wrong ignoring existing technical details. But those mistakes largely come down to having someone who cares and understands the language and technology not for the lack of solutions. There are probably plenty of interesting edge cases that might not be handled perfectly even though solutions for basic cases exist, but article doesn't come even close to discussing those technical details especially if it's only conclusion is "computers introduced more problems, notably because of Unicode".

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.

Even better if keyboard keys (1,2,3,4) were also supported.

If that's a the goal, then IT department should start by blocking user ability to install Firefox or other unapproved software not by blocking access to google workspace. Blocking access to google workspace using Firefox doesn't prevent using it for everything else. It's not like the google services are going to exploit a vulnerability in Firefox, everything else might.

Whether you get controlled bit flip depends on exact encryption mode used. Haven't seen any document with enough technical details on how exactly their encryption scheme works.

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.

Consumers were always capable of disabling it themselves if they didn't need it. The performance impact seems to be ~3% on average, impact on power consumption is probably similar or less since any extra delay idling can destroy performance while not having as big impact on power consumption. https://www.phoronix.com/review/amd-memory-guard-ram-encrypt...

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.

AMD has limited control over what motherboard manufacturers do. And there have been plenty of examples demonstrating motherboard vendors don't fully understand what they are doing. Stuff like shipping builds with example/placeholder keys, ridiculous voltage settings which destroy the cpu. Even if motherboard vendors don't have full control to configure to freely change every flag, they probably have access to some kind of debug/development firmware which has a lot more features enabled than what you would have in consumer builds.

Git is currently industry standard tool for software development, which means that almost every IDE and code editor has good and mature GIT integration. It will take a while for Lore to achieve similar level of support. Considering the intended usecase seems likely that they focus the effort on integrating into game engines and game development specific needs instead of making plugin for every last code editor. Not only code editor but every other software related tool interacts with version control - code review tools, CI, package managers and code forges. That's a lot more work than just creating a version control system. Why waste effort on areas that already have good alternatives.

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.

All sources point that their 2025 models are still using brushed rotors. Here is a teardown video it's from Nisan car but it's using a Renault electric motor https://www.youtube.com/watch?v=BFmp9ODkCA8 .

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.

Did anyone commenting about Qt and how it makes sense actually looked at the result?

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.

The problem here wasn't that frames in single animation had different sizes, but separate animations. The example images are a bit misleading since they show only one frame from each animation.

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.

Flipper zero was an arduino with half a dozen sensor, radio and other communication modules. Flipper one is a laptop/mobile phone class system in weird form factor no doubt its going to be more expensive. No point even comparing them. You can't call it a price hike if it's completely different category of product. There have been plenty of openish tinkerer laptop/mobile phones projects to know that paying high end laptop price for a device with compute power of last generation raspberry pi is a likely outcome.

No UB, but the integer promotions rules apply.

When comparing signed and unsigned integers of same size the signed one will be converted to unsigned. In a reasonably configured project compiler will warn about it.

In case of integers smaller than int, promotion to int happens first.

In case of signed and unsigned integers of different size, the smaller one will be converted to bigger one.

The licensing information is very conflicting

Hardware and software that belongs to everyone. Waiting to be OSHWA certifie

Hardware & Industrial Design All rights reserved. The hardware design, including but not limited to Are proprietary and the intellectual property of Juan Ramón. No commercial use or reproduction of the hardware is permitted without express authorization.

Same for software, the comparison table says MIT, other parts say GPL v3.

Also the whole concept of exam mode which is in any way effective seems contradictory with GPLv3. Any hardware means which would limit the ability to use modified version of software would violate GPLv3.

Even if you are completely skeptical about the AI cad model generation they also demonstrated their representation for model search/matching. Having a smarter search method for cad models based on 3d geometry in addition to traditional text search would be nice to have.

When skimming a research paper in addition to abstract don't forget to read "limitations and future work" and "conclusions".

In the limitation section they are quite direct with it: "images used .. are mostly isometric and noise-free CAD-images" and "limited CAD vocabulary used in this study needs to be extended by including more sophisticated CAD tokens such as revolve operation, edge operation (e.g., fillets/chamfers)". It currently supports only series of pads (can be subtractive). Many simple beginner exercises of seemingly similar complexity don't fit those constraints. Some of the parts shown could be more naturally created using wider set of tools, but technically can be created using only pads.

So even if you tried with clean screenshot of simple 3d model, it will likely fail if camera settings aren't right, and it will fail if model can't be represented using series of pad operations. Anything containing spheres, cones, nearly all lathe parts, fillets which can't be included in 2d sketches will fail. In theory arbitrary extrusion angles are supported, but all examples showed only axis aligned parts.

That said I wouldn't be surprised if it failed even if you considered exact limitations not just similar complexity in your attempts.

Assuming images in the googledrive are the training data, "mostly isometric and noise-free CAD images" is a bit of understatement. All of them are at very specific angles using and single style. Specific solid gray infill color for "images", and white infill with weird shading around perimeter for "sketches". Both with white background and pixelated non antialised 1px lines. No reason to expect it capable of processing anything which doesn't have exactly same visual style. For practical product that would have to be solved but that wasn't really the point of this research. All the style transference papers have show that it's more or less solvable problem, but for a paper exploring what model architecture and 3d representation could work best for AI cad it seems like unnecessary distraction that would only bloat the training costs and time. Most annoying part is that it makes hard to test the model with your own inputs.