Steam Deck is currently ~25% of those 5% Linux users. Good chunk but not a majority. You can estimate it in two different ways which produce similar results: filtering to Linux only looking at OS list "SteamOS Holo 64 bit" is 24.48% and in the GPU list "AMD Custom GPU 0405"+"RADV VANGOGH" add up to 23.72%.
There are more than dozen different viewport navigation manipulation modes, latest version added two more (Solidworks and Siemens NX). You can pick whichever behaves closest to the program you are most used to.
Yeah, I tried all of them with all the combinations of presets and orbit styles and the closest I could get was using tinkercad but couldn't match the orbit style correctly.
It is in the bottom right corner when clicking (i) button just like the https://osmfoundation.org/wiki/Licence/Attribution_Guideline... suggests. The only questionable part I see is that after page reload it flickers for half a second and then gets automatically hidden instead of getting hidden after manual interaction with map. Is there any other point in attribution requirements that it doesn't comply with?
I could've sworn it wasn't there before - but maybe I also just missed it since it is covered by the half-transparent panel (on mobile) and all the other stuff around it distracted me.
This is my mistake, mobile is/was a mess and I was only really looking at desktop before posting. It was buried behind the misplaced bottom bar. Fixed now.
Twitch can forward the stream as is without transcoding it. That's what transcoding not being guaranteed means. It will be a worse experience for viewers but it can work. Few years ago they even announced working with OBS on feature where streamers themselves can transcode and send multiple streams further reducing need for twitch to spend their compute resources on unprofitable streamers.
Most of those 160 pages, is repetitive mish mash of various historical research (many of questionable quality) on typeface readability loosely grouped by certain themes retold in a way that makes it even less clear about their results, quality and whether testing conditions are useful for making any good conclusions.
Little value in reading it all unless you follow references and read what the quoted research actually did and said. The chapters have different thematic, but content and conclusions are very samey -> a bunch of questionable research and research which was inconclusive or didn't observe significant overall advantage of serif vs sans serif.
As for where it came from to me it very much feels like the defense of serif typefaces is largely typographers defending existence of their craft and people talking past each other with overgeneralized claims. There is definitely value in the art and craft of typography and I respect that. It would be too bland if everything used plain sans serif fonts that barely differ from each other, and you can definitely mess up typography making text hard to read when done badly. But I also believe that there is plenty of things based on traditions and "everyone knows x because that's how we have always done it".
As for sans serif for screens the obvious reason and also thing that comes up multiple times is low resolution text. At certain resolution there are simply not enough pixels for serifs. The author of paper suggest that with modern high resolution screens this argument doesn't stand.
My personal opinion is that it's not a big issue at sufficiently high text size. But even on somewhat modern 2560x1440 screen I can find plenty of UI elements that have only 7-8 pixels high labels. Not everyone is using retina displays and not everything is long format text. Screen resolutions have increased, but so have information density compared to early computer screens, although there is recent trend of simplifying UI to the point of dumbing it down and adding excessive padding all over the place.
There are other screens beside computers and mobile phones, many of them not very high resolution even by standards of early computer screens. It doesn't make sense to put high resolution screen and Linux computer in every little thing. Problem is made worse by lack of antialised text sometimes due to screen, sometimes MCU memory and compute limitations. You are probably not going to have modern font rendering stack on something like black and white washing machine screen, gas station pump or thermostat
The research multiple times mentioned stuff like low resolution, but it hardly ever quoted hard numbers in a meaningful way. How many pixels a typeface needs to be comfortably represent serif? How many arcseconds? Surely there must be research related to that one. This might be part of problem for some comparative research - can't compare readability of serif/sans serif if there is no serif typeface at those resolution. Stuff like point 10 or point 12 without additional details is meaningless.
Some personal anecdote -> text antialising has huge effect. Made a sample text of serif and sans serif font and zoomed out to the point where lower case letters are ~6px high. I wouldn't expect there to be enough resolution for serif but you can perceive surprising amount of detail in letter shapes. Zoomed in on screenshot it's a blurry mess, but at normal zoom level the serif letters are fine. It's readable but wouldn't consider either of 2 comfortable. When scaled up to 8px both pieces were still harder to read than same height text in UI labels. Why is that? Why is one identical height sans serif text much more readable than other? Are UI labels better pixel aligned? Is it due to subpixel antialising? That's on a 90deg rotated screen, is subpixel antialising even working properly there?
Just for fun switch OS UI font to serif. Due to font sizing inconsistency it ended up being 1 pixel shorter (7px) than same size default UI font. Can those even be considered serifs when they are hardly a pixel each? It felt weird, nowhere near as bad I expected, but still weird.
The link was posted by project's author so probably should have been Show HN.
Feels more like AI slop list of "a bunch of hardware that you can buy from hobbyist electronic stores" which has no idea what it wants to be, shiny on surface but deeper you look less sense it makes. Not surprised, the company who made it (likely single person) describes itself as "We're crafting interesting tools to speed up software development using Artificial Intelligence."
Good chunk of that stuff is not open hardware by any definition -> neither the hardware design being open nor the firmware not even community written firmware for proprietary hardware.
If you ignore the poor description of the site is the parametric search at least good? The values in parameter dropdowns seem to be filled based on currently displayed items, that might be fine for narrowing down once you already made a search but for initial search it means you get random subset of available values. The fact that whole thing is non-categorized, random mix of mismatched type of hardware doesn't make the parametric search better. Good parametric search needs well curated and structured database of descriptions made by people who understand corresponding product category, otherwise it's garbage in garbage out.
Having to wait half a minute while AI is reticulating splines even when you used quite specific keywords isn't a good search experience either.
So if it's not a good list of open hardware, not a good list of hardware you can flash open firmware, not a good search for electronic components what is it good for? Only value I see is as a fuzzy set of links and ~~tags~~ for exploring a subset of related hardware topics.
Edit: not tags those are broken. #tags return error, other tags(uses cases) and other other tags(compatible firmware) in many cases returns only 1-2 results which doesn't even include the item where you clicked on tag even though there are a lot more items using it.
we are scraping the products using Claude Opus and we also saw some problems.. we will have to review everythign manually and improve (not an easy job.. but if it's useufl for people, we will do it -- i did not expected so much demand for it)
Regular variadic arguments in general aren't used very often in C++ with exception of printf like functions. Not rare enough for majority of C++ programmers to not know about them, but definitely much more rare than their use in python. Main reason people know about it at all is printf.
The "new" C compatible form has been supported since the first ISO standardized version of c++ if not longer. There haven't been a good reason to use the "old" form for a very long time. Which means that the amount of C++ code using deprecated form is very low.
Being deprecated means that most compilers and linters will likely add a warning/code fix suggestion. So any maintained project which was accidentally using C incompatible form will quickly fix it. No good reason not to.
As for the projects which for some reason are targeting ancient pre ISO standard c++ version they wouldn't have upgraded to newer standard anyway. So if new standard removed old form completely it wouldn't have helped with those projects.
So no you don't need to know the old form to read C++ code. And in the very unlikely case you encounter it, the way for accessing variadic arguments is the same for both forms through special va_list/va_arg calls. So if you only know the "new" form you should have a pretty good idea of whats going on there. You might lookup in references what's the deal with missing coma, but other than that it shouldn't be a major problem for reading code. This is hardly going to be the biggest obstacle when dealing with code bases that old.
The article answers to this near the very beginning.
> Now, don't get me wrong. Trigonometry is convenient and necessary for data input and for feeding the larger algorithm. What's wrong is when angles and trigonometry suddenly emerge deep in the internals of a 3D engine or algorithm out of nowhere.
In most cases it is perfectly fine to store and clamp your first person view camera angles as angles (unless you are working on 6dof game). That's surface level input data not deep internals of 3d engine. You process your input, convert it to relevant vectors/matrices and only then you forget about angles. You will have at most few dozen such interactive inputs from user with well defined ranges and behavior. It's neither a problem from edge case handling perspective nor performance.
The point isn't to avoid trig for the sake of avoiding it at all cost. It's about not introducing it in situations where it's unnecessary and redundant.
More like the opposite. Point cloud data captured with varying means has existed for a long time with raw data visualized more or less just like this. And SciFi movies/games use the effect of raw visualization as something futuristic/computer tech looking. Just like wireframe on black background, although that one is getting partially downgraded to more retro scifi status since drawing 3d wireframe isn't hard anymore. It started when any 3d computer graphics even basic wireframe was futuristic and not every movie could afford it, with some of them faking it with analog means. Any good scifi author takes inspiration from real world technology and extrapolate based on it, often before widespread recognition of technology by general population. Once something reaches the state of consumer product beyond just researchers and trained professionals, the visuals tend to get more polished and you loose some of the raw, purely functional, engineering style.
reply