I definitely was thinking of Comic Sans. Both in terms of the horrible typeface and the “not funny” connotation of the name. (Yeah I know sans is referring to lack of serif)
It might have been pretty horrible but I hold Frontpage 97 with fond memories, it started my IT career, although not for HTML reasons.
The _vti_cnf dir left /etc/passwd downloadable, so I grabbed it from my school website. One Jack the Ripper later and the password was found.
I told the teacher resposible for the IT it was insecure and that ended up getting me some work experience. Ended up working the summer (waiting for my GCSE results) for ICL which immeasurably helped me when it was time to properly start working.
Did think about defacing, often wonder that things could have turned out very much differently!
It’s funny this came up, because it was kinda similar to the whole “AI frauds” thing these days.
I don’t particularly remember why, but “hand writing” fancy HTML and CSS used to be a flex in some circles in the 90s. A bunch of junk and stuff like fixed positioning in the source was the telltale sign they “cheated” with FrontPage or Dreamweaver lol
My only gripe was that they tended to generate gobs of “unsemantic” HTML. You resized a table and expect it to be based on viewport width? No! It’s hardcoded “width: X px” to whatever your size the viewport was set to.
Some of the “smaller sources” also distorted facts.
We might even have fewer than before - between Internet commentators and loss of confidence from AI, real journalism may not be as highly valued as it was before the Internet…
It will entirely be about trust. I don't think fakery is worth it for any company with > $1B market cap as trust is such a valuable commodity. It isn't like we are just going to have a single state broadcaster or something like that (at least, I hope not). However it is going to favour larger / more established sources which is unfortunate as well.
They want to use rust but can't, because they need C compatibility, e.g. because they're providing a library or wants to support platforms that rust don't.
It's at least a less bad idea than I expected originally – I've mainly seen people try to use transpilers to sneakily start using the language they prefer as part of a larger code base, with all the obvious problems.
It's still not great as you now have an additional translation step to deal with. You will at some point need to look for bugs in the generated C layer, which will really suck. Users of the C library can't read your source to understand what it does internally without an extra step to figure out what rust code the thing they use corresponds to, etc.
If you want to provide a C library, write C. If rust isn't an option because it doesn't work for your customers who use C, don't use rust.
You can write a C-compatible binary library in Rust (see the cdylib target) and cbindgen can then generate proper C header files for any C-ABI interfaces exposed in Rust code. A full Rust-to-C compiler should only be needed for targets that have some C compiler available but are just not supported by the current Rust toolchain.
You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library? What would be the point? The C ABI is quite compatible across toolchains.
> You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library?
The Rust-to-C conversion would be done by the Rust library author (or more likely, some automated CI process) to create a C source code distribution of the Rust library.
reply