Successfully ran Gemma4-26B-A4B on my 8yo first-gen Ryzen with a GeForce GTX 1070. It actually ran acceptably well; I was surprised. I even did some coding with it, but the wheels fell abruptly off when it tried several times to use a constant I told it doesn't exist. I only have 32 GiB of RAM in this old bucket, and these results are not worth the RAM consumption, so I put it aside. Maybe if I finish that build with more memory...
It looked like a mere word processor, but—much like Emacs, especially org-mode—the Canon Cat was actually contextually aware of what the text meant, and allowed other operations to be performed on it as appropriate. For example, if you start typing numbers into tables, spreadsheet-like functionality became available, including the ability to perform mathematical operations over those numbers and have cells dynamically updated with the new values. Raskin called it a "work processor".
The Forth language was available for programming and extending the machine, via a cheatcode. You had to type in the phrase "enable the Forth language" and evaluate it with a special command or something—you know, one of those things to provide hackability for those who needed such while keeping it an office appliance for the vast majority of users. I don't know if there was an intent for a market or library of third-party software, but that doesn't seem to have arisen.
Unfortunately from an organizational perspective, a bad hire could cause so much damage through incompetence let alone malice, that making no hire the default unless they're a perfect cinnamon roll of a fit, is actually a good strategy.
> a bad hire could cause so much damage through incompetence let alone malice
The fact that an organization cannot deal with such a case is a bigger problem in the first place. Eliminating incompetence and malice is among the basic skills of an organization.
What if a bad apple is hired despite all the checks? The system should be able to detect and eliminate bad apples before they give “so much damage” regardless of when they are hired.
Of course the organization should do its best to avoid bad hires. It should do so because of the opportunity cost of not hiring the right person, not because of the damage that they might give to the organization.
I was actually hired at my current job to replace a worker who was let go because pretty much from day one, she was acting suspiciously, consistently with someone who was outsourcing their work to contractors and splitting their paycheck with them. Posing a significant risk to the confidentiality of corporate IP and data, from day one, despite putting on a convincing game face throughout the interview and selection process.
In light of this kind of threat, strongly favoring no hire, and even policies like mandatory on-prem work, start making a whole lot of sense.
The case supports my argument though. Trying not to hire a bad candidate is not a resilient strategy. Someone might fall through the cracks. You still have to screen the candidate after the hire. Heck, even not hiring is not a good strategy, because someone inside may turn bad.
I remember Chad Whitacre primarily as the proponent of Fair Source, a putative solution to the open-source free-rider problem and probably the best solution I've seen so far aside from just making your software proprietary which comes with disadvantages of its own.
To be honest, retiring completely from tech is something I wish I could do as well...
reply