That sounds fun. I tried to design an assembly game once, but found I lack the creativity to design puzzles/goals that are not just "implement this common algorithm in assembly language". The idea of bootstrapping a PC from virtual firmware and writing an OS sounds nice, though.
HN user
SoothingSorbet
It's uniquely inconsistent (many distinct toolkits with irreconcilable look-and-feel, even in the base system)
While I agree that Windows has long since abandoned UI/UX consistency, it's not like that is unique: On desktop Linux I regularly have mixed Qt/KDE, GTK2, GTK3+/libadwaita and Electron (with every JS GUI framework being a different UI/UX experience) GUIs and dialogs. I'm sure libcosmic/iced and others will be added eventually too.
I still find this explanation confusing because decoder-only transformers still embed the input and you can extract input embeddings from them.
Is there a difference here other than encoder-only transformers being bidirectional and their primary output (rather than a byproduct) are input embeddings? Is there a reason other than that bidirectionality that we use specific encoder-only embedding models instead of just cutting and pasting a decoder-only model's embedding phase?
I wonder, is there a good reason to use Dillo over something like Netsurf or Ladybird nowadays? They support far more of the Web (i.e. more likely to be useful) while still being lightweight.
but sadly, the secrets of how I am doing it are in Intel’s proprietary cblas_sgemm_batch() function.
Perhaps you can reverse engineer it?
Please explain how you would solve the iterator invalidation problem using only C++ and RAII. Thanks.
Java solved it with a JAR file
JARs still require a JRE to run, and the runtime needs to be invoked. The equivalent would probably be a Python zipapp (which are just Python files zipped into a .pyz the interpreter can run).
Static binaries are one advantage that languages like Go and Rust have though, yeah.
I love your idea of using it for compression.
I didn't notice a link to any code, would you be open to sharing the code? I'd love to take a look at how you did things and play around with it myself.
Ballmer also gave us the maligned Windows Vista and Windows 8. Microsoft has also been way more open source friendly during Nadella's tenure, whereas Ballmer was openly hostile to FOSS. I'll take Nadella, thanks (although he should fix his user-hostile spyware).
I don't know if Google has changed their position, but Mozilla is willing to accept a memory-safe (read: Rust) JXL decoder [1].
If it becomes used in Firefox, maybe there's a chance that Google would see the benefit in picking it up?
[1] https://github.com/mozilla/standards-positions/pull/1064
Yes, CanvasBlocker for Firefox does this: https://addons.mozilla.org/en-US/firefox/addon/canvasblocker
e.g. For me it shows a new unique fingerprint each refresh.
Why managed when it could be in Rust and have both performance and safety?
The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?
1. non reproducible is there in the API
It should be reproducible if you set the temperature to 1, have you tried that?
However, the telemetry of VSCode is non-personal metrics
I don't care, I don't want my text editor to send _any_ telemetry, _especially_ without my explicit consent.
some of the most popular extensions are only available with VSCode
This has never been an issue for me, fortunately. The only issue is Microsoft's proprietary extensions, which I have no interest in using either. If I wanted a proprietary editor I'd use something better.
There's no difference there because the types are already disjoint.
Say you wanted to define some function taking `YYMMDD | MMDDYY`. If both YYMMDD and MMDDYY are just aliases to `str`, then you gain no information, you cannot discriminate on which one it is, since the union `str | str` just reduces to `str`.
Sum types are disjointed unions, you can't just say `str | str`, the terms are wrapped in unique nominal data constructors, like:
enum Date { MMDDYY(String), YYMMDD(String) }
Then when accepting a `Date` you can discriminate which format it's in. You could do the same in Python by defining two unique types and using `MMDDYY | YYMMDD`.
Indeed. And importantly, you could tell exactly which UI elements were which. It's sometimes genuinely difficult to tell if an element is text, a button, or a button disguised as a link on Windows 10/11.
Windows exists to enable the user to do whatever he wants
It's very bad at that, then, considering it insists on getting in my way any time I want to do something (_especially_ something off of the beaten path).
If the user wants to play a game or watch a video, Direct3D is there to let him do that. If he doesn't, Direct3D doesn't get in the way.
I don't see what the point you are trying to make is, this is no different on Linux. What does D3D being in the kernel have to do with _anything_? You can have a software rasterizer on Linux too. You can play games and watch videos. Your message is incoherent.
I'm sure Windows is perfectly capable of driving a GOP framebuffer. That doesn't mean the kernel has an actual GPU driver.
That's interesting, why would notepad.exe use mmapped files?
Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created
Wouldn't that just consist of I/O operations returning futures and then having an await() block the calling thread until the future is done (i.e. put it on a waitqueue)?
Linux has changed dramatically since its first release. It has major parts rewritten every decade or so, even. It just doesn't break its ABI with userspace.
The screenshot is not "ugly", but I agree that the README is functionally useless -- no documentation, no examples, no indication of why I'd want to use this. Fails on a fundamental level to communicate what it's about.
What "sucks" about it? Since they added type checking it's been perfectly fine, besides the notable omission of nullable types (which is... a strange omission, to be sure).
PDB (which isn't documented)...
What about https://github.com/Microsoft/microsoft-pdb ? Not technically documentation, but the closest thing to it.
You can jump to the address and then declare the data as a struct.
It is annoying though that you can't make the register display show a particular type, it only shows unsigned hex integers. If I'm tracking a 32-bit float it is very frustrating, it won't even show you alternate representations on hover...
For as good and expensive as IDA is, the UX sure is lacking.
There's also panda[1], but I never got it working myself. I share your frustration, as it would help greatly with debugging, especially with nondeterminstic bugs. I likewise never got QEMU's record/replay to work.
I've been waiting on that game since 2010, and it seems to have no release date, so it just might! I wish they would just break it into smaller pieces to have something to ship and iterate on.
The game has been in development since 2009 and, as of April 2024, does not have a release date.
I'd also appreciate a comparison to DB Browser for SQLite (https://sqlitebrowser.org/)
Looks good, I have a few questions about the project:
- Is there an Android app or is it Web only on Android? (This is very important for playback on video player apps, which support more than the Webview does.)
- Is there a Flatpak available?
- Why did you choose to use a big server like Postgres over using SQLite? Did it not meet your needs? It seems way overkill for a personal media manager. Are there any plans to at least support SQLite as an alternative in the future?
They do, you may just not look very much into the ecosystem.
OSes - redox and many other smaller projects
git - pijul is novel, gitoxide is a pure-Rust git reimplementation
vim - Helix, based on vim and kakoune
a lot of C code will be made memory safe in the future without needing a rewrite in Rust.
Sanitizers don't do what Rust does, and static analyzers cannot make C memory safe. You would have an easier time of bolting a borrow checker onto a subset of C++ than what you're thinking of, IMO.