I actually can in my 1995 Suzuki carry (kei truck). It’ll stick off the end of the bed because the bed is a bit over 6 feet not 8, but the bed is completely flat, no wheel arches. And the whole truck is no longer than a modern hatchback, it just packages it aggressively. It is truly an amazingly practical vehicle.
It isn't a bitmap font. It's Berkelium64, which is a re-work of a Commodore GUI font for GEOS with a fair amount added. It's proportional, rather than monospace, and it only looks like it is a bitmap.
Your retort is ableism. Some people have vision problems such as myself and I find reading the cute yet blocky font to be very uncomfortable. Thankfully, reader mode fixes this.
bitmap fonts were the norm on computers for many years, and are still the default if you are running a computer in text mode (ie not running X11 or Wayland on linux / BSD), or using basically any low powered device with a screen. I was surprised to hear that anyone had trouble reading these, since they were just what fonts looked like on screens with certain constraints. I can understand that some people have become so used to high DPI displays and antialiased truetype fonts that they consider fonts with visible pixels ugly. If anything I would expect them to be easier to read with poor vision, since there is not much subtlty to miss out on.
I perfectly understand bitmapped fonts. I've used computers since 1983 when my eyes were young and had little problem reading blockly bitmapped fonts of 8-bit systems on TV screens.
At my age now, things are harder to see, even with glasses I find myself using magnifying glasses and flashlights to improve detailed vision. That being said, the font of the site is so ridiculously blocky that it is almost illegible to me. If that plea doesn't move anyone then I guess we have a society that doesn't value accessibility.
English-only was also the norm for many years. First you make it work, then you make it accessible. But there's no reason to dial back on accessible formats once you have them.
NetBSD noob question: what’s going on with this command? Is pkg_add not a package manager? If you already have pkg_add why do you need pkgin? I am familiar with `pkg` on FreeBSD, and `pkg_add` on OpenBSD, but they are both perfectly good enough on their own, I never wanted to install another package manager.
If you are familiar with FreeBSD, then the parallel answer to the others in this thread is that on FreeBSD there's the bootstrap pkg that you get in base and the pkg that's in the ports tree itself. It's not quite the same, but the general idea holds that there's a less featureful package installer in base and a more featureful one in the package system itself.
So you can also just use the second command and not set PKG_PATH, or atleast not for every session.
I prefer to do it that way since pkgin has its own repository config, and if I use pkg_add after installing pkgin it'll be to install packages from the pkgsrc and that might clash if PKG_PATH is set.
You will note that timeline also maps quite well on when electric vehicles started to become viable in the market . Of course battery technology also had a lot to do with that, but efficient high voltage power electronics absolutely are an important part of the equation.
I mean sure, motor control existed before solid state switching devices, but it was also much lower efficiency and used much lower voltages. Power electronics absolutely are critical for the efficiencies and handling characteristics of modern electric propulsion.
It is a derivative work, isn’t that appropriate? Or are you saying it shouldn’t have blender in the name unless it’s owned or officially sanctioned by the company that owns the blender trademark?
You can work around that. If you have an application that also has a command-line option, then you could create a UI for that application with this library. The UI module for your application will have to be under GPL because this library is licensed under GPL. But your core program can still be closed-source, as long as you distribute both parts separately. A bit convoluted, but I've seen some applications that do this - they don't distribute the GPL code directly, but ask you to download it separately. (In fact, if I remember right, they had done the opposite of what we are discussing - the developer had created a closed source UI for an open source GPL application, and asked the users to install the open source application through Linux package managers). As far as my understanding of the license goes, this conforms to the GPL only if (1) the GPL code isn't essential or a core part of the application, and (2) you don't distribute both as one application (which implies that the GPL part is absolutely necessary part of your application, thus violating the first rule).
I think the benchmark is for layout performance not JavaScript execution, but v8 is fast because it emits assembly more so than because of the language it is implemented in. That said, I would be very surprised if there is not hand tuned assembly routines for performance critical routines.
My point was that while you can implement any performant program (be it V8 or Spidermonkey, Blink or Servo) in any language, the effort required to reach a certain performance level differs between the languages.
>v8 is fast because it emits assembly
It emits machine code afaik. And secondly, do you _really_ want to implement the intermediate layers of a JIT in assembly?
I take your point that code organization in assembly is hard, and not worth the performance gains over higher level languages. It’s true, we don’t write much complex software completely in assembly.
However the point I was trying to make is still relevant I think, which is that machine instruction abstraction layer (whether it is serialized as binary machine code or as assembly text) remains a critical piece of what makes high performance software fast even today.
There is a recurring myth I see on HN that suggests abstraction layers are progressive, as though humanity had evolved past the assembly/machine instructions abstraction layer to C to higher level languages leaving lower abstraction layers behind completely. That is simply untrue, and a project like V8 is actually a great example of this, since it not only will have hand tuned assembly routines, but also needs to ship a bespoke compiler which will emit machine instructions.
So even though it’s true we don’t organize our software with assembly language, it remains a key to performance. It could be a custom JIT compiler, hand tuned SIMD code (eg to handle string parsing), or even just checking what the compiler emitted (eg in compiler explorer). Machine instructions remain key to high performance.
You don't seem to know where the machine code are generated from. A big part of a compiler is optimizing intermediate representations of the source code.
I’m not sure what you hope to prove by bringing up ir. I am quite familiar with it, but I don’t see how it’s relevant. Chrome v8 will have inline assembly routines for specific architectures for various fast paths as is pretty much standard in most high performance code. Compilers are not as good as hand tuned assembly especially when SIMD is involved. Just as a basic example strlen or memcpy in a libc implementation work this way on most targets.
As for ir in the Jit compiler, that is an implementation detail as far as I’m concerned, because the V8 guys had to write the bit that goes from IR to target machine instructions. My point there is that compiler authors need to understand assembly, which is just as true with IR as not. IR is just more convenient for implementing optimizer passes that may be common across architectures (ie where the abstractions hold)
does this mean if you want to add some print statements for local debugging inside a pure function that you will have to remove pure from the whole callgraph? or is there a way to treat it as just a warning?
it seems like in this case SIMD is one of the biggest reasons libdeflate beats miniz-oxide. at that point you are either using assembly or a library of functions that maps in names and functionality to the assembly. I think C isn't really better than other languages in that regard. Its not like its using auto-vectorization to get that SIMD support.
reply