The entire reason for integer under/overflow to be undefined is to enable compiler optimisations. If you're going to be using unsigned anyway, we might as well drop the undefined behaviour from the standard and just say it's machine-defined. That should honestly be the correct choice. If a loop is hot enough to benefit from those optimisations, you can easily rewrite it in a form that makes the compiler assume overflow won't happen. Either using current syntax with unreachable(), or we can add a runtime_assume(expr) expression that signals to the compiler that it can assume expr is true. Though for full safety I would prefer using if(likely(expr)) {fast code} else {panic or return error}.
As an aside, unsigned does not save you from undefined behaviour. When sizeof(short)==2 and sizeof(int)==4 (e.g. x86, x64, arm32, arm64), then multiplying two unsigned short values happens by upcasting them to ints (see integer promotion rules), which can overflow the int.
My personal opinion is that along with making signed overflow defined, unsigned integers should be entirely removed as a type and there should instead be separate signed vs unsigned operators, because at the processor level there is no difference between the two, and there hasn't been a good case to separate them at the hardware level for the last ~half century. Basically, do what Java does with some syntax like unsigned{expr} which forces all integers inside expression to be treated as unsigned. Unsigned literals can stay, but they will be bitcast to signed equivalents if used outside unsigned context.
Reverse engineering may be easy for really simple inventions, but quickly becomes so hard you may as well invent the thing from scratch. Look at USSR's domestic chip production. At one point they succeeded in reverse-engineering chips like Intel's 8086, VAX etc., but chip design very quickly became so complex reverse-engineering the entire chip became impossible. I would say if an invention can be easily reverse-engineered, then it is a simple foundational idea that should not be patented, and if it is truly innovative, then it cannot be reverse-engineered easily and doesn't need patent protections.
Then there is the fact that when something is patented, that has a chilling effect on competition, making the market less efficient.
There are also a lot of really silly patents that end up benefitting no-one, not even their inventor, but only result in needless litigation. The recent lawsuit between Nintendo and PocketPair comes to mind.
While there are cases in which patent law can help individual people profit from their invention, once all consequences are tallied, the overall effect of patent law on society appears to be negative.
In general I would like to see a web browser escape sequence for console applications. Just send a command to the terminal to connect a web browser to your stdin/out and present any UI you want over html. The terminal can then open a regular socket listening on localhost and act as a CGI server. For security the terminal should pick a random IP in the localhost range and a random URL. Technically that is security by obscurity, but guessing a cryptographically secure URL should be hard enough for attackers. The reasons to do it as an escape sequence and not just have the application open a socket and start the browser are: To enable remote GUI; To avoid the complexity of each application implementing networking; To enable better desktop integration, since the terminal itself is part of the Desktop Environment, so it can start a DE-specific browser, preferably in single-application mode. Also, it should be possible to automatically put the application in the background so you basically just run GUI applications like normal.
Wayland was started 18 years ago. When it was conceived, X11 was 20 years old. In 2 years, we should probably start talking about replacing Wayland with a modern display server...
In all seriousness, it is another stark reminder why you never rewrite from the ground up. Especially when you're replacing a foundational technology like the display server. In the same time Microsoft reworked their display driver model twice without requiring a single change from application developers. The Linux world doesn't have that many application developers, we should not be asking them to continually chase newer and newer APIs. A rolling stone gathers no moss.
> To do both, they’ll have to guarantee that that column of water stays isolated from groundwater for a long time after the fuel is used up.
I wonder if just letting the water gradually dissolve the uranium might not be fine, actually. If it is done far from wells and rivers used for drinking water, then the small amount of radioactive minerals that slowly seep out might not pose a danger. I can't find any studies to back it up, but I imagine there are places on Earth at which enriched uranium buried 1.6km underground poses no threat. I am no expert, so I would love to hear what others think.
This sounds like a gaming club. A small one, but a gaming club. Those exist, we have them all over. You pay for them in a variety of ways, in this case the way being forced seizure of wealth aka taxes. Other ways are via profit from sales of consumables (what the article alludes to) or membership fees. In all cases it is the parents that pay for them. It is absolutely possible for the market to build a non-predatory gaming club, but I concede it is easier when you can just get a government grant. It is entirely possible nobody in Stockholm can run a gaming room as a profitable business. Profitable businesses are hard even when they are simple.
The rest of the article can basically be summed up with "work takes too much time and pays too little", which is absolutely true.
I am not sure what the jab at stay at home moms or grandparents who help with childcare is supposed to be. Probably some other communist drivel. Grandma absolutely did not do unpaid childcare, she was insistent she had to teach us right and also got tons of labour and money from my parents. If the exchanges of money and labour between parents and grandparents in the context of childcare were measured, it would probably double the nation's GDP.
> That was probably the most surprising part of the entire experiment: internally, Windows has changed enormously over the decades, yet the application interface has stayed so stable that code written in the mid-1980s still looks completely familiar.
Imagine if Linux stuck to that same level of interface compatibility. Think of the thousands of man-hours lost to rewriting perfectly good code just chasing the new shiny thing. In an OS built by volunteers we're wasting all developers' time to rebuild their software for the new interface, instead of having on developer spend time to keep the old interface working with the new implementation. And don't try to go "uhm akchyually Linux is the kernel and the kernel is stable", nobody cares. I mean the whole OS, from the kernel to the GUI layer. Is it any surprise that the best tools on Linux are all console programs using the POSIX interface, which has remained stable for the lifetime of the OS?
I would go as far as to say that GTK is the Linux Desktop's original sin (followed closely by Qt). Motif and CDE were already established as the Unix GUI API, they should have been reimplemented with an optional separate GTK-native API. Maybe the next generation will learn from our mistakes.
What is the issue with building for Windows 7 target on Windows 10/11 host? Not that the team is obligated to support ancient OSes, but I am not following their justification. If it is just the fact that they can't properly test if the build works on 7, then they could call it "best effort" support.
That is a clear-cut case of extortion. The defence is having the police do their job and apprehend the criminals in question. If you screen incoming messages and stop them from reaching their target, extortionists will switch to publicly releasing one risque image with threats of releasing more explicit ones. There is always an unprotected channel as you noted.
As an aside, please do not use the b-mail word. It is insensitive towards BIPOCs.
Eh, every term for disabled people becomes a slur. Moron->idiot->retard (the latter being so unacceptable in modern speech it is labelled by the kids as "the hard r"). But you are right, we should simply not use terms for disabled people in software names. I propose "Thirty Years and Still Cannot Draw a Circle" or the hip short name :no-entry-sign: emoji.
Ideally I would want the code review to be versioned as well with easily accessible history. That is, I would like to see the exact lines which a comment pertains to and when they were changed and switch back and forth. While e-mail is probably good enough as a protocol to exchange this data, the e-mail client is not a good way to view it in my opinion. Maybe we need a decentralised code review system as well.
Wouldn't this break Go and other build systems (npm?) that pull packages from github by default? Not that I endorse the practise, but will Microsoft really kick out such a big class of users?
I honestly do not think source code will be all that useful. Make it so redistribution, decompilation, reverse-engineering and reimplementation is legal after sales stop and that covers it.
Joe can walk into an Apple store (or wherever they purchased the device) and ask them to enable parental controls on it. We have people whose job it is to service computers and phones, they have been around for more than half a century. I am pretty sure most Joes don't service their cars either, yet they keep them road legal by visiting trained mechanics.
Parental controls can set browsers in "child mode" where the browser sends an "I am a child" header to the server and social networks etc. need to honour it. This has existed for twelve years already: https://blog.mozilla.org/netpolicy/2014/07/22/prefersafe-mak... . It can probably be amended with a more granular set of levels, but that would be the best way forward.
The problem of "parents are negligent" is also solved by existing laws which have fines for parents who are negligent towards their children, and governments absolutely love collecting fines, so all the incentives are properly aligned.
Or keep stealing IMEI IDs. Now regular people will start getting banned from the internet because of bot activity. You would open your phone one day and see "You have been disconnected from society" and there will be nothing you can do.
Google would throw homeless people in a furnace to generate electricity for their datacentres if they could. No, this is not sarcasm, I fully expect they would if they could.
As an aside, unsigned does not save you from undefined behaviour. When sizeof(short)==2 and sizeof(int)==4 (e.g. x86, x64, arm32, arm64), then multiplying two unsigned short values happens by upcasting them to ints (see integer promotion rules), which can overflow the int.
My personal opinion is that along with making signed overflow defined, unsigned integers should be entirely removed as a type and there should instead be separate signed vs unsigned operators, because at the processor level there is no difference between the two, and there hasn't been a good case to separate them at the hardware level for the last ~half century. Basically, do what Java does with some syntax like unsigned{expr} which forces all integers inside expression to be treated as unsigned. Unsigned literals can stay, but they will be bitcast to signed equivalents if used outside unsigned context.