Please, literally every other country in the world store their petroleum reserve in surface tanks. We have fifty years of experience in designing the safety systems around oil tanks, and the only recent major incidents are from drone strikes in Russia and Saudi Arabia. Just because the US luck out in having the specific geological formation to store oil cheaply doesn't mean the alternative is untenable.
> It would be sufficient to store dry salt
Absolutely impractical. Storing and moving around solids in the megatons is very difficult compared to liquids that can be pumped. For comparison, the absolute largest solids moving operation in the world is a copper mine in Chile, it moves 300,000 metric tonne of mineral per day. The east-west pipeline in Saudi Arabia can move three times that in liquid, 1,000,000 metric tonne per day.
For me, the ability to mount a backup and look at a particular file proved to be important. Also, I restored from my backups four times; two of them was moving between machines, pretty quickly.
If I lived in Australia, I would have the exterior of my house to be very white (except solar panels), so as to reflect most of the visible and IR light, and stay cooler.
Problem is most newer places are built of concrete or brick. I mean sure slap some white paint on but the that thermal material is going to take a lot of cooling/heating.
> Tailwind looks ugly, but there are no hidden abstractions or structures in the code
Verily, Tailwind is the assembly language of CSS. No structure, no semantics, no abstractions, only twiddling specific bits of visual representation.
To turn to it is to admit that your product lacks the structure and the design vision that allow to use some abstraction ("semantic classes"), and that all you can usually do is to patch some areas of it, disconnected from the rest, and unable to touch the rest (lest it goes down in flames). Assembly is definitely suitable for patching.
This is often the endgame of old large products that changed hands and directions many times, without much care.
This seems like a radical, unsupported conclusion to draw from a single frontend architecture decision.
Maybe there's an overwhelmingly positive case to be made for high-abstraction CSS with hidden structures. Outside those few select cases, we've known the tradeoffs for 25 years, and the added complexity is rarely worth it.
I enjoyed working with a semantically styled frontend project as recently as 2024. It also used a React component library, which helped insulate per-component styles, while sharing the common parts.
It has. It's called @apply. It works fine. The Tailwind author is wrong about recommending people to avoid @apply. The Tailwind community at large is mostly wrong about it too (except people that like and use @apply).
I don't know how anti-abstraction came to become popular, but if you like semantic classes you can still use Tailwind. (why use Tailwind? It has some nice defaults and a coherent design language)
The anti-abstraction crowd, that push for repeating the same boilerplate over and over again, honestly grinds my gears. Even assembly doesn't make writing boilerplate its ideology (it has macros, and actual subroutines)
There were and are many important pieces of Linux kernel that live out of tree; ZFS is a big example.
The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.
Most state is buffer-local rather than global. Note also that there is already some amount of multi-threading in elisp.
One thing you could imagine is doing some kind of mvcc system so that if two tasks don’t interfere with each other, they can execute in parallel (and if not, abort one and rerun it sequentially).
But maybe that still doesn’t work because all the things that should be run concurrently are using the same buffer and doing manipulations of it. You could imagine trying to make save-excursion introduce an opportunity for parallelism: split into a separate thread for the body as that thread is no longer modifying global cursor state (in some sense). Don’t let two threads write to the same buffer for concurrent tasks that should appear sequential, but do allow them to read in parallel (surely most things are merely reading).
However I’m not sure you actually need all that cleverness. I think you could have some combination of:
- tools to make multithreaded elisp more viable
- manual attention to improve major sources of slowness by introducing parallelism (eg font-lock, rendering, autocomplete, indentation). A stupid thing could be precomputing (in the background) what would happen in the user pressed RET (or TAB) and then being able to execute it sooner if they press that key.
The question here is whatever Steam Frame displays resolution is sufficient to work with text. So far only mass produced device that was really suitable is a Vision Pro.
So far all reviews I've seen been centered around gaming and not work.
It is said that human eyes can resolve down to 1 minute of arc(1 MOA or 1/60 degrees). Each eye has about 160 degrees of HFOV and 125 degrees of VFOV.
From there, you can work out requisite resolution for desktop replacing VR googles: 11K per eye.
The catch is that human eyes actually only have
~1 degree of full resolution area and ~30 degree of active area, and the full 200 degree HFOV is only realized by moving them around and subconsciously compositing images, so most of panels can bee left unlit, in theory.
But the panel resolution requirements is the same, and our technologies are just not there to make a true desktop replacement VR goggle, yet.
For me personally the Quest 3 is absolutely unusable for any text work. Even small font in games looks shitty. This is so far off for what it ought to be for comfortable work that I'll wait for devices with at least double the resolution per axis, i.e. 4x the pixels of the Quest 3 screens to even bother trying again.
Edit: And I'm writing this on a 32" 2560x1440 display which looks just dandy to me, so it's not like I'm super sensitive or have above average eyesight (quite the opposite actually)
I have tried this in the past and it wasn’t nearly sharp enough but I guess I see people using 1080p screens at work and those make me want to rip my eyeballs out.
I guess from the comments we can draw conclusion that its different to everyone.
I had Quest 3 for a few months to play games and I feel okay playing, but every time I tried to open IDE and terminal after 10 minutes my brain just say full stop. I tried different fonts, themes and zoom levels, but it just feel wrong.
I feel similar feeling of discomfort as if I try to work on something not in computer in low light in real world. Might be it have something to do with my bad eyesight.
I honestly did not tested AVP enough. Its just good enough for me not to immediately want to stop using it, but again I have no idea what would really happen after a week of use for 3 hours. I did it once for a few hours and it felt amazing, but its Apple and there lots of other reasons not to buy their locked down hardware.
> every time I tried to open IDE and terminal after 10 minutes my brain just say full stop.
I'm wondering if it is because the screen was "flat" in front of you and you had no possibility to change your perspective. It would be interesting if the IDE had been in 3D space and you would look at it as if it was on your desk, capturing head movements etc.
This is certainly interesting idea, but I guess main problem isnt just UX and representation on 2D surface, but just pure amount of text data that you suppose to look at and understand what exactly it does.
When you have fiction or game dialogue text there is good bunch skimming going on so you dont care about every single symbol and or digit. So eyes dont get stuck looking at specific parts of text.
So yeah its very much possible that using VR as a virtual monitor setup it's just wrong aproach and there have to be paradigm shift in how we interact with dev environment to use it efficiently in VR.
For me it's more that flights are extremely boring. I find watching any movies or TV shows on a plane to be a horrible experience. The noise of the plane can ruin even the best of movies.
Maybe better for a train; the benefit is that when you unfold your bike for the last mile, you just put your work into partial transparency and navigate using the external cameras.
Also only possible if you've got a power outlet (Surprisingly even today many long haul flights do not) as its only got just over an hour of battery life.
It has a 21.6 Wh battery. You can easily get a power bank 3+ times this capacity, thus can last 4x longer. If anything, I would rather have that weight in my pocket or backpack than on my head, all things considered.
Anecdotal, but on the last few flights that I've taken. I was told that you can use them, but you can't charge them on the flight. This was inside the US, American Airlines, and United. I can't speak to the other airlines.
In constrained plane environments https://github.com/vk2diy/hackbook-m4-mini works well and has long battery life. I fix the screen to the seat using adapted helping hands and use a wireless keyboard/mouse for input. Super comfy as long as your eyes can deal with the reduced distance (look down the aisle occasionally).
Magnifying style shop glsssed might actually be perfect for this. I use them for electronics repair (they also only focus close which is sort of a benefit here). Downside for me is they fit in a way that is too high (they are designed for looking straight ahead) that would be great for this
Using it while flying will be complicated by the fact that all airlines have banned the use of power banks. If the onboard USB socket isn't very powerful then you'll only get an hours' use.
I can confirm that all the flights I have been on this year we were told not to use power banks. You can have one with you (well you have to since you're not allowed to check large lithium ion batteries) but you aren't allowed to actively use it.
I've flown on half a dozen different airlines this year and all have had exactly the same stance: no power banks in checked luggage, and if they're in hand luggage you must be able to see them at all times (not in overhead storage).
You're also not allowed to use them even if you do have them with you. This is all very strictly enforced with reminders at the check-in desk and several announcements before take-off.
100 W sockets? All the flights I've been on that provided power have had a really low current USB A port that can barely keep my phone from discharging when the screen is on.
> designed to ignore the rest of my system as much as it can and live in its own little world.
Exactly what a small, locked-down system needs. A single-purpose server box. An advanced appliance, like a "smart TV", or media box, or an advanced home automation hub.
I don't see why this calls for a new system. If anything these environments are a stronger case for a quality ecosystem where a whole community cares about keeping it coherent and up-to-date.
A minimal Debian installation for single-purpose server isn't a new idea, or I often reach for Alpine and trim it down to a dozen or so packages. These are both quality ecosystems with track records and reputations. I can get a minimal attack surface and still count on timely updates, security patches, good integration (when it turns out that I needed a dual-purpose server box and not a single-purpose box), etc. These systems scale up and down.
What I'm reluctant to trust in a deploy-and-forget system is a fly-by-night package from someone who picked a packaging system because it looked easy and didn't make them think about an actual lifecycle. A few months or years down the road I expect most of those will be unmaintained. One of the most valuable parts of an ecosystem like Debian is that they make everybody think about all those issues and actually do the work.
TIL, I didn’t know that. I always assumed it came from level zero”, the Intel computer layer that ZLUDA was translating to before its developer was hired by AMD to target HIP.
reply