"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly acknowledge that, your bug will be closed automatically in 30 days. Thank you very much"
> What are you building? Does the tool help or hurt?
> People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era.
I'm assuming you're saying these tools hurt more than help?
In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model.
PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined.
And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing.
It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.
Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases).
That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.
(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)
Ironically, SQL Server AFAIK in order to run on Linux uses what basically amounts to a Microsoft reimplementation of Wine. Which always makes me wonder if they'll ever get rid of Windows altogether someday in favour of using Linux + a Win32 shim. I think there are still somewhat strong incentives nowadays to keep NT around, but I wouldn't be that surprised it this happened sometime down the line.
AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf
Having done a multi targeted project in the 2005 range. I can tell you. The APIs that both systems provide are quite expansive and do quite a bit. However there is a mismatch on details and gaps. In this case the NT mutex system is 'there' in linux however the way it works is subtly different. You have to basically emulate waitforxxxxxxobject set of windows calls. Getting that right and performant can be quite a challenge.
My particular challenge was similar in around how threads were created destroyed and signals between them (such as mutex). We ended up making our own wrappers to insure the different platforms acted the same. Even something simple as just moving between two supposedly 'same' linux distros could be different depending on what the ODM did to their packages and supported libs. Having a dedicated linux object that acts exactly like the windows one would have made that code much simpler to do.
Another place where there is a huge impedance mismatch is in the permission system. In many ways the VMS/NT way is wildly detailed. Linux can do that but you have to emulate it or use it directly and hope you get it right on both sides. There are several places where windows/linux have the same functionality but the APIs are different enough that multi platform support is kinda awful to do.
Read the last sentence in that paragraph, those numbers are a bit disingenuous:
> Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
A lot of what Proton-GE brings from my understanding is a larger support for Media Foundation, which can't be added to Proton itself because of license issues (Proton is from a commercial company, where Proton-GE is from an individual).
So aside from the stuff that has been implemented differently, running Proton instead of Proton GE is like trying to game on Windows N editions.
There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).
macOS sucks! you need a ton of third party tools and customizations to make it sane for basic things like window management. It's no better than Windows with regards of ammount of tweaking needed for power users.
And it scans every executable and command run and sends a hash to motherbase. I don't know how people put up with this. There's probably some dangerous way to disable that like, let me guess, disabling SIP...
I've installed linux (debian LTS with XFCE) on my mom's computer and she recently called me to thank me. She says her computer is much quieter now (meaning fewer notifications). She only needs a web browser and a text editor.
So you're right, it's great for power users, it's also great for other users.
Window management: only if you are the kind of power user who needs complex layout. I have used Windows for decades and have used Mac on and off, and have even bought one of those window management app on MacOS, but never needed to use them. In rare occasions where I need several windows open, side-by-side on each of dual screens is usually good enough, if not I probably am working in a terminal where I use tmux.
Gaming: that's a fact but again doesn't matter to most people. Most people play video games on phones/tablets/consoles if they play games at all. PC gaming is a relative minority, and (regular) Windows laptops can only do lightweight gaming anyway. The amount of people who decides what "everyday computer" they should buy based on whether they are going to play games on it is very small. Plus, you get much better ROI by buying a PS5+Macbook Air than spending the same amount of money on a gaming laptop.
you need a ton of third party tools to make it behave like Windows, that's what you mean.
I'm perfectly happy with my "vanilla" macbook. Runs Baldurs Gate 3 and my final fantasy ps2 emulator just fine, and even trackmania was quite easy to get installed and runs well.
Can't comment on that hash thing, but I don't see why that would be a problem? It's not linked to your name or something. Windows does a ton of things too that I find inexcusable, such as changing settings or permissions after updates, those have an actual impact on my daily experience with these things
Fair enough on the iOS mention. The tech stack (React Native, Expo, TypeScript, SQLite) is detailed in the blog post, I wasn't trying to hide it.
As others pointed out in the thread, RN renders actual native views, not a webview. For this use case: browsing a local SQLite database offline, it works really well.
Funny enough this was my first mobile app ever, I figured it out doing it. Expo helped a lot. The Apple review process on the other hand… that was a whole learning experience on its own.
RN does use a lot of native code. It’s not based on a webview like Electron is. Most of the builtin components are native views and there’s no CSS. The JS engine is also simpler. It’s more akin to the lua runtime in Neovim.
It’s a fair assumption. The React part is more about copying JSX and other React concepts (declarative UI etc) but it all boils down to native binaries. The toolchain is also pretty nice. It does hot reloading so you don’t have to recompile the app while building locally. The downside is you get less for free compared to SwiftUI. But SwiftUI also has many footguns and bugs. No free lunch!
"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly acknowledge that, your bug will be closed automatically in 30 days. Thank you very much"
reply