More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Our kids at school are using https://cscircles.cemc.uwaterloo.ca/ for an introduction to Python and it seems they're making good progress (age 11 to 14)
It's available in German (and maybe other languages), too.
QLab is the bomb. Ten years ago, at least, it was deservedly ubiquitous at every level of theatre: it's massively powerful, but progressively complex. That is to say, basic features are super-simple to learn, set up, and use - I was able to teach novice users how to create sound plots in... an hour? - then the more-advanced features build on that familiarity in relatively straightforward ways.
Furthermore, I once contacted QLab's technical support for help with an ambitious effect - it was theatre in the round, and I wanted sound to shift through six speakers, arranged behind the audience, to dramatize a "chase" sequence. It seemed like it should be completely possible, but I couldn't get it to work. Their tech team took a look at my plots, agreed that it should be possible - and that it wouldn't work was due to a bug - and then shipped me a pre-release version with the fix, all within, like, two days.
I've seldom loved a software product or company more.
If I were still in this game, however, I'd take a close look at Cuelist. It might solve the problem I had with my touring show, where local techs had to track three different places - script + my QLab deck + their lighting deck - to run the show. With very limited rehearsal that was usually too much for them to keep up with, and cues inevitably got dropped.
It'd all depend on how easily Cuelist connects to different lighting boards, and how efficiently house crew could add their light cues into that interface. Cudos to them, though, for coming up with a new UI that looks like it could be really great.
WeVPN indirectly approached us to "make their users whole" for the time that they had paid for. In the spirit of collaboration, and not further tainting the already murky image of the consumer VPN industry, we decided to comp every WeVPN users with free service for the duration of their remaining subscription.
This is a goodwill gesture only, we're not engaged in any official partnership with WeVPN, and are/were not affiliated with them in any way.
Buddhism encourages doubt (in most lineages). There is a sutta where the Buddha said:
> “You have a right to be confused. This is a confusing situation. Do not take anything on trust merely because it has passed down through tradition, or because your teachers say it, or because your elders have taught you, or because it’s written in some famous scripture. When you have seen it and experienced it for yourself to be right and true, then you can accept it.”
I don’t know. This hype-crypto-machine is not catching up with my “feelings” about the future of the Web. Maybe I am getting old, but aside from some communication protocol usage and some form of authenticity (which is questionable), I don’t see web3.
I would go out on a limb and say that if this is web3, I don’t want to have anything to do with it. This is an outrageous waste of resources and energy with awful environmental impact, driven primarily by pure greed and wishful thinking.
Looking at mindset of the VC’s, which are giving this “things” validation, scares the living sh*t out of me.
More and more, implementation of modern ‘tech’ is pushing me towards abandoning the ship and moving into the woods somewhere.
Don’t let me start with NFT’s. It is horrible. The impact of this thing over a lot of my friends is getting ridiculous. I somehow understand “the money” aspect (ponzi scheme, money laundering), but recently I got “the cult” vibes from some of them and closed the door permanently.
So hard “no” from me. I already have a “Metaverse” in which I feel comfortable, it is called reality.
Specifically, the "iNES header", originally created by Marat Fayzullin for use with his NES emulator, iNES[1].
If you look at the iNES manual[2], way down at the bottom in the changelog for version 0.7, you can see "Sound support completely rewritten, thanks to Kawase Tomohiro".
If you search the Internet for Kawase Tomohiro, you'll find[3] somebody by that name seems to work for Nintendo as a programmer, and in particular worked on the NES emulator used in 2001's Animal Crossing.
Of course, that's not conclusive evidence, but given the competing claims "Nintendo, a notoriously uptight company, has been downloading pirate ROMs to sell" versus "Nintendo hired a pioneer of NES emulation to work on their emulators, who kept using the tools and formats he was used to", I feel like one is more likely to be true and the other is more likely to get ad impressions.
One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time.
React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SPAs. Now if you aren't building an SPA you look around and find almost every resource is around building an SPA. Even if you know you don't need an SPA, it's easier to hire, iterate, and even use other open source solutions if you are building an SPA, so you try to hamfist your project into an SPA.
It's a bit like having a bike commute in America. A bike might be the best thing for you to do - cheaper than a car, keeps you healthy and you don't need a garage. But you quickly find that everything is built for cars and it's easier to deal with the disadvantages of a car than try to commute with a bike.
I remember thinking the same thing about Hadoop 5-6 years ago. If you had "small data" you could get what you wanted with SQL and fast disks. But everything else assumed you were on Hadoop. Newgrads were trained in hadoop. New tools were Hadoop first. New research was all hadoop. If you hit a small issue with your DB, almost every solution would be "this is how it's solved in Hadoop". It was hard to even know if what you were trying to do what even possible without Hadoop.
The only optimism I have is that maybe in 5 years we will all collectively wake up and stop trying to shove React everywhere just like we stopped with Hadoop.
I think what the "legacy" news media failed at more than adapting was effectively communicating the time and effort that goes into serious news gathering and reporting. I regularly get the impression a certain slice of HN commenters think "the media" is a bunch of opinion bloggers fabricating sources to drive "an agenda". In reality, the effort for producing a deep investigative story can be equivalent to an a mid-size software engineering project in terms of person hours and expertise. Three senior reporters working on a Pulitzer-level story can take years, numerous support staff, and legal fees.
Most software engineers innately know that taking an open-source project, stripping the authorship, putting it your own site and running ads next to it is unethical, regardless of the licensing etc. Yet, when it comes to capturing news stories of equivalent production effort, "information wants to be free". I think that may largely be a failure to understand the work that real reporting takes.
Ironically, as prestige newsrooms have shrunk, the percentage of high-quality stories has gone down because revenue has declined and those stories are expensive. So in fact we do perversely end up with more click-bait as Google et al engineered systems to optimize for attention and click-through (the opposite of a multi-part investigation).
The first bookmark on my bookmark bar is "Kill floater", and it removes most floating elements on the page. It even works on many sites that hide the page behind a popup. Use it on my iPad all the time.
I don't like either extremes. I quite hate working in big bloated IDEs. But I don't like trying to accomplish everything at the terminal. I always use GUI and shell tools together.
My editor of choice TextMate is usually launched from the terminal. I work a lot in a REPL environment and when I get a stack backtrace my terminal program iTerm2 automatically identifies paths in the stack backtrace, so I can mouse click them and open in TextMate at the correct line.
I use a separate git GUI client called Tower a lot, but I also use the git command line. I mix and match a lot.
I really dislike monolithic tools. If you try to do absolutely everything from the CLI you get many of the same problems as in a IDE GUI: You get too much complexity in your interaction. Too many special keystrokes and commands to remember.
I quite like the old NeXT idea of an IDE, kind of how the old xCode was when interface builder was a separate program. As you integrate more tools complexity just grows.
We already have a multitasking OS with windows. We where meant to use multiple tools and not just sit in one big maximized monolithic program.
I've been running my macOS desktop in an ESXi VM for over a year now. I came from a hackintosh, but got tired of the fragility of some upgrades. Some notes on this setup:
- Apple supports macOS running inside of ESXi. Officially, only on Apple host hardware (i.e. a Mac Pro, which is on the ESXi compatibility list). Apple even ships a VMXNet3 network driver in macOS.
- For ESXi specifically, you have to patch the host to boot macOS on non-Apple hardware. There's an explicit "am I running on Apple hardware?" check in there. DrDonk's unlocker on GitHub is what you need.
- You can specify board-id, ROM/MLB, etc values via your .vmx file. iMessage and everything work for me, but I'm also using identifiers from a real Mac Mini I retired a few years ago. I expect this will still work okay with generated data if you follow hackintosh guides.
- I pass through a GPU and a USB controller card for input/output. For USB, find an FL1100 chipset card, like the Inateck models, which works out of box on macOS, Windows, etc. Recently I moved my boot drive to a passed-through NVMe for extra speed. My other drives are ESXi virtual drives backed by storage elsewhere on my network.
- Most NVIDIA GPUs will need the NVIDIA Web Drivers to work. Kepler generation cards are the last to work out of box, and the only to currently work out of box on Mojave. If you don't need hefty performance, a GeForce GT 730 is a cheap card. Apple and NVIDIA are still not getting along, so I expect this will only get worse.
- However, I've never been able to get an AMD card to initialize via passthrough. The PCI device is seen, but the EFI strings or whatever else Apple is using to determine initialization paths are wrong. I recently spent awhile trying to figure this out, going so far as to write my own SSDT tables for the device, but finally gave up.
- This particular guide is using Chameleon, which is considered an outdated bootloader. Clover is far more flexible, and will work in VM setups that don't natively implement SMC like ESXi. (For the longest time Clover would crash an ESXi VM, but this now works as of a month or two ago).
And finally, on the context of this whole thing--I switched from a real Mac Pro to a hackintosh years and years ago, when it became clear Apple didn't care about upgrading the hardware. They still don't. The last Mac Pro release was 2013 (the 2013 iPhone was a 5S!). They've been promising things will improve "soon". They're the world's most valuable company; if they actually cared, at the organizational DNA level, it would have happened by now.
Way back in the day, I was working on a project to extract your score from a bunch of old ROMs across various platforms. Developers picked some insane ways of storing even something as simple as a score. The very worst I recall was some old game about, I think, catching falling pots or something. Instead of just storing a 4 digit number, they stored the score as 4 pointers to the location where that digit was stored in memory. They'd increase your score by adding a multiple of the images' size to that location, and they handled overflow manually. I assume the idea here was screen rendering performance, but it didn't seem like it could possibly be worth it.
This happens to include a nice two-paragraph summary of how password hashing works, that I think a non-technical person could easily understand. It's a shame they used the term "string", but it reads fine in context. I should save for future use...
-----
> If you have a Google account, Google’s core sign-in system is designed not to know your password. How, then, can we verify your password when you sign in to your Google account again? The answer lies in a bit of cryptography: when you set your password, instead of remembering the exact characters of the password, we scramble it with a “hash function”, so it becomes something like “72i32hedgqw23328”, and that’s what we store with your username. Both are then also encrypted before being saved to disk. The next time you try to sign in, we again scramble your password the same way. If it matches the stored string then you must have typed the correct password, so your sign-in can proceed.
> The effectiveness of the hash function lies in its one-way nature: it is simple to scramble your password, but nearly impossible to unscramble it. So, if someone should obtain the scrambled password, they won’t be able to recover your real password. The downside of password hashing is that if you forget your password, we cannot show you what it was; there’s nothing we can do other than reset it to a temporary password (valid one time only) and then require you to pick a new one.
> You could do better by knowingly tuning RGB values—or, even easier, HSV.
Yes, I've been doing generative art (e.g., https://i.redd.it/1tuvtfuwsfz11.png, https://i.redd.it/ymg1ix4t8qu01.png), and one of the challenges has been learning to think about colors differently. At the beginning, I would add a bunch of colors randomly to the art. Recently, I've learned some things about what makes colors look good together.
Basically, colors have three "axes": hue (is the color red? blue? yellow? green? purple? etc), saturation (how _much_ of the hue is there? low (but not 0) means pastel; high means neon), and brightness (low is black, high is bright). Play around with the axes here: https://codepen.io/HunorMarton/details/eWvewo (not mine)
If you're going to have different colors that conceptually are on the same level (e.g., four colors for tiles in a grid; three colors for different generated trees), keep two of the axes the same, and vary the other. You can see one example I've done (https://imgur.com/dFGu9Wg) where I vary the hue, but keep the saturation and brightness the same. In another example (https://i.redd.it/ymg1ix4t8qu01.png), I believe there are two colors, but each one keeps the hue the same and I vary the brightness.
[1] https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html