You can separate stairwell and elevator hall/apartment hallway with an open balcony like they do in some countries. This way smoke from the rest of the building can't get to the stairwell. This is called smokeproof enclosure.
The real story here is about bad JS KeyboardEvent API. I think a lot of JS code in the wild does these incorrect checks and author's code after "fixing" the bug is still incorrect. When handling keyboard shortcuts you want an exact match, in this case you want to check that the only modifier used is Ctrl. JS API does not make that easy, you need manually check that all other modifiers are not pressed.
Why not just have time as close to solar as possible and move working hours as needed? I have always found arguments for permanent summer time very confusing. Just move working hours as needed, why do you need to deviate the entire clock from the solar time for that?
Because we no longer live in a pre-industrial society where people start work with the sunrise and go to bed at sunset, because the only available artificial light is candles. For the vast majority of people, noon is not the middle of the day.
Because many people for some reason don't strongly value the derivative of the solar inclination being zero and a local maximum within at most slightly over 30 minutes[1] of an analogue watch having the hands both vertical, on the few days a year that the equation of time is zero.
[1] Because the equation of time might not be exactly zero at noon, the Earth isn't a perfect ovoid and you could be up to 7.5 degrees of longitude from the centre of an hour-wide timezone, even if you drew them perfectly straight down the globe with no regards to national borders.
Interesting perspective. I'd like to use that and say that we should have solar noon in the middle of our "awake" hours instead of in the middle of our work hours. This would benefit even more. We're not in a society where your activities are from dawn to dusk, more so, it's usually from dawn to dusk+evening time.
So, let's take the assumption that the average awake time is 7:00 - 22:00. Gives us 15 hours of awake time.
Solar noon should be at 7:00 + half of the awake time: 7 + 15/2 = 14.5 = 14:30
To calculate sunrise on the longest day and shortest day we use: 14.5 - half of light time
To calculate sunset on the longest day and shortest day we use: 14.5 + half of light time
This means sunrise and sunset in Amsterdam:
summer, longest day, 16:48, 16,8 hours:
- sunrise: 14.5 - 16.8/2 = 6.1 = 6:06
- sunset: 14.5 + 16.8/2 = 22.9 = 22:54
winter, shortest day, 7:41, 7.683 hours:
- sunrise: 14.5 - 7.683/2 = 10.6585 = 10:40
- sunset: 14.5 + 7.683/2 = 18.3415 = 18:20
Given this reasoning, instead of being GMT+1, Amsterdam should be GMT+3 all year round
How do you expect stores to coordinate? If they worked during work hours, what's the point? People work during work hours, they don't go to stores. To solve this stores work around the clock or until 21 hour.
I don't. That's the whole point. Many/most stores, schools, companies, etc. are open about the same hours year-round. To the degree that people prefer those hours shifted relative to the sun at different times of the year, using DST provides that coordination at the cost of everyone having to change their clocks (or having a computer do it for them) twice a year.
What I find frustrating about Microsoft Store is that it only shows you ratings and reviews from the same country you are from. For me most apps have one or zero reviews and maybe like 5 ratings.
Not everyone would be learning English as a second language. In many parts of the world you may need to know some regional language in addition to your native one, so English would be your third, not second language.
> AI-Generated review summary: We are making it faster and easier for customers to scan reviews for apps by using the power of AI to compile thousands of reviews into a simple summary, enabling customers to discover new content with ease.
Would be cool to have an option to actually read those reviews. If I open Firefox page in the Store app it says 420 ratings but I can only read a single review. If I press 'See all' it just shows an empty page. If I open Firefox store page[0] in the browser it says 'No one has reviewed this application yet. Be the first to add a review.' Reviews seem to be split by country or by some other criteria for no good reason.
They are promoting tightly packed structs as fast. For high-performance language I would expect native struct-of-arrays support because structs are bad for CPU cache and SIMD.
The keyboard itself looks good but hardware vendors (including keyboard manufacturers) have a track record of making abysmal software. In fact, software should probably be their primary focus. From their FAQ it look like they want themselves to add support for every application. Will they have an SDK for other software vendors to add support to their applications? Being more open, e.g. making a github repo where anyone can contribute support for any application would be welcome.
This keyboard is a computer. They should have built a server of some kind (REST API, whatever) to manage the keyboard and documented it. They could provide a client for Windows, Linux and Mac OS developers would have built one or many of them for their OSes.
If you are running untrusted WASM files with wasmedge be aware that it doesn't sandbox by default. WASM can contain native code that will be executed without sandboxing. From the docs [0][1]:
> The wasmedge CLI tool will execute the WebAssembly in ahead-of-time(AOT) mode if available in the input WASM file.
> The wasmedgec can compile WebAssembly into native machine code (i.e., the AOT compiler). For the pure WebAssembly, the wasmedge tool will execute the WASM in interpreter mode. After compiling with the wasmedgec AOT compiler, the wasmedge tool can execute the WASM in AOT mode which is much faster.
They added an option (--force-interpreter) to disable running untrusted native code [2]:
> Thanks for reporting this. I think we can have a flag to disable the automatically loaded AOT sections from an unknown given universal wasm format. One possible situation is that users want to execute a wasm file with interpreter mode, however, they use a universal wasm format received from a malicious developer, and then the bad thing happens.
Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI.
For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.
What's the purpose of having 4 linear color spaces (srgb-linear, xyz, xyz-d50, xyz-d65) for interpolation? Linear interpolation is exactly the same in any linear space. Indeed, in provided gradient examples these 4 look the same.
Because they're (idealy) not linear, I'd assume. Gamma correction[0] is an exponential-like function. Hence, sRGB vs "sRGB linear". Despite what many people think, sRGB color #808080 is not 50% the brightness of #ffffff, but about 75%. All because our eyes are non-linear.
Color math is a massive rabbit hole that deserves its own "things programmers believe about..."
The CSS Color (Level 4) spec allows you to interpolate in any color space that you can specify colors in, and all of these four are considered useful to specify colors in. (Or at least useful enough to make it into the spec :-) ) This leads to some redundancy in this specific context, but the alternative would be disallowing three of them in interpolation only, for no good reason at all.
