whew… I was worried I was going to be the only one to hammer the article. Fluff pieces like this are the reason I stopped reading business advice books or articles altogether.
We use msdf textures. Generate them dynamically when people upload fonts. We tried 3 methods, and we're sticking with msdf for now because its very fast.
> We really don't want open war between the Western powers and Russia.
True. But unfortunately Putin loves playing on that fact to keep us frozen and hesistant to send aid.
Ukraine’s recent advance into Kursk shows you how little his supposed red lines actually exist.
And to the often held claim that NATO is a threat to Russia and is to blame for making Russia move into Ukraine, Russia’s actions in Ukraine betray this little myth. They’re depleting the stocks of expensive tactical ballistic missiles as well as very expensive high end surface-to-air missiles by hucking them at even tiniest targets in Ukraine.
This isn’t what you would do if you were actually worried about needing to confront aggressive, well funded western neighbors later.
In one of those ironies that seem to populate modern life, the now public ineptitude of the Russian military in Ukraine has in fact given some western military leaders an inkling that directly taking on the Russians is a viable option.
> you do want a defined subset of HTTP/(X)HTML. Maybe to make a small web HTTP, servers can reject clients that e.g. send user agents, and clients can refuse to render pages that contain a script tag.
That’s a great idea.
My idea was to go other way a bit re javascript. That is, allowed it to run but it’s under the control of the user, not the website. A bit like installing a native app. For anything functional, why not have companies just send JSON or have an API and the user can display as they see fit. sending sqlite files around would be another option.
I can’t help but thing that in the future people will laugh at how ridiculous we are with stuff like the l fact that the service provider can make me chase my tail around intentionally obfuscated UI in order to cancel.
> [A small web HTTP, with a defined subset of HTTP/(X)HTML is] a great idea.
It is not the only way, although it is one possibility.
> My idea was to go other way a bit re javascript. That is, allowed it to run but it’s under the control of the user, not the website.
Simpler designs can be made than JavaScript with HTML DOM. But, when it can be allowed, yes it should be under the control of the user and not the website.
> For anything functional, why not have companies just send JSON or have an API and the user can display as they see fit. sending sqlite files around would be another option.
I had a similar idea (although I think there are some problems with some file formats such as JSON, too).
However, it does help to be able to specify which files can be used to display unknown files. My Scorpion protocol/file-format specification includes such a feature called a "conversion file"; both server-side and client-side conversion are possible. It is optional to implement, but if it is implemented, the specification requires that the user is allowed to override it with their own specifications if desired.
> Simpler designs can be made than JavaScript with HTML DOM.
I'd agree here for sure. I suppose I was thinking that if JSON (or any other basic format) was specified in and out from companies, etc; a client-side browser replacement could be about anything. I think the fact that current browsers are 100s of millions of lines of code (or whatever) get in the way of the fact that, at its core, a browser doesn't have to insanely complex.
You need a way to put info on a screen and a way to talk over the network. That's pretty much the core. Not hard to add some flavor of storage and/or scripting client-side.
I've only toyed with a bit, but I think something like the Lua Love2D tool pretty much gets you there. Or any number of approaches.
> although I think there are some problems with some file formats such as JSON, too
Curious what you think those problems are. I'm not defending it particularly and have heard a few valid critiques tossed around online but am always open for hearing how folks think about it. Personally, I'm largely surprised that anything has managed to coalesce into a general format for data.
> My Scorpion protocol/file-format specification includes such a feature called a "conversion file"; both server-side and client-side conversion are possible.
Cool, I'll go take a look for it.
Feel free to ping me at the email in my profile if you're up for kicking any ideas around.
The topic has been sitting on my mind for a long time and I'm glad to get behind anyone's even half plausible technological approach. I think our 60 years of Moore's Law makes any one of a number of approaches possible. But prob not just me plugging away here solo in my living room.
> Feel free to ping me at the email in my profile if you're up for kicking any ideas around.
I did not find a email address in your profile.
However, I have a NNTP server and can use that to set up a public discussion forum for such things. Some of the appropriate newsgroups in Usenet might also be used (e.g. comp.infosystems and/or comp.protocols.misc) if you like to use that.
If you have a GitHub account, then the GitHub issue tracker can also be used for discussion of specific issues with the specific project (the Scorpion protocol/file-format specification, and the programs related to it (e.g. client and server software)).
> I suppose I was thinking that if JSON (or any other basic format) was specified in and out from companies, etc; a client-side browser replacement could be about anything.
Yes, and I think that such a thing (whether or not it uses JSON) is helpful. However, there would then also be something to specify display of such files (which the user can easily override with their own).
> You need a way to put info on a screen and a way to talk over the network. That's pretty much the core. Not hard to add some flavor of storage and/or scripting client-side.
Yes, and there are ways to do it. I think that uxn/varvara is a simple way to do it (especially if you only need one network connection at a time, since it can be connected to the standard I/O; you can disable the file device for security if desired), and is what the Scorpion conversion file specifies (although the conversion file is flexible and can be used to specify other things too, such as server-side conversion).
It doesn't need to be mandatory for clients to implement all (or any) of the features. But, if some features are implemented and the user is not required to use those provided by the server, and can also provide their own (the specification for the conversion file Scorpion protocol, requires this), then it can be less of a problem. (The use (and presence) of the conversion file itself is deliberately made optional, though.)
> a browser doesn't have to insanely complex.
Certainly it shouldn't have to be insanely complex, if it is better designed.
> Curious what you think those problems [about JSON] are.
Criticisms of the data model:
- Not a proper integer type. Although you can write 64-bit (and longer) integers, the corresponding type JavaScript is 64-bit floating point, and long integers are unlikely to work even in implementations that do not use JavaScript. (JavaScript does have a big integer type but these are not used in JSON.)
- Unicode string types. The use of Unicode string types in programming languages and general-purpose file formats isn't very good. It can be inefficient and can make assumptions that are not always valid such as that all data is text and that all text is Unicode and that all file names are Unicode, and then there is the handling of surrogates, etc. Byte strings are better; you can still store Unicode text with byte strings, but also any other data. (Using hex or base64 to the data model just adds additional steps; although such features could be appropriate for the text-based syntax of the file format.)
- Keys. They are influenced by the way keys are handled in JavaScript, which sometimes has some special cases that are not as clean as they could be. (In JavaScript you can use Object.create(null) to avoid the automatic handling of the keys that are inherited from Object.prototype, but this does not apply to the literal object syntax.) (I think keys should be integers and byte strings; JSON only allows Unicode strings, and JavaScript does not distinguish between numbers and strings as keys.)
Criticisms of the syntax:
- No optional trailing commas (even though JavaScript allows it).
- No comments (even though JavaScript allows it).
The things mentioned in the syntax are not applicable for binary formats (although different considerations may be relevant), although can be relevant if you want a text format as well.
(One possible alternative would be a subset of PostScript, rather than a subset of JavaScript. PostScript already has a binary format as well as a text format (although the binary format cannot use numbers longer than 32-bit integers and 32-bit floating point; and limits strings to 64K; these limits might be too small for some applications), has byte strings, has a hex syntax for byte strings, and does not use commas between items.)
> Cool, I'll go take a look for it.
There is a GitHub repository of Scorpion protocol/file-format specification (and some programs) at: https://github.com/zzo38/scorpion
The specification file can also be accessed by Scorpion protocol itself, at: scorpion://zzo38computer.org/specification.txt
They have done some new road-marking over the last couple of years but I remember that when I briefly commuted into Boston (and sometimes drove) it was pretty much chaos when school started up and a lot of people weren't familiar with the traffic flow.
Extreme focus on the stock price and thus highly short term thinking. The accountants run the show and try to aggressively cut costs at every corner which works really well in the short term, but over time the company gets decimated and nobody can take the bigger product risks that allow a company to continue to evolve.
tl;dr: Keep cutting costs way past the point where it kills the ability to innovate, maintain quality, or survive an unexpected shift in the business. Cover that with low-bidder outsourcing until that fails. Meanwhile hit the talk shows (on media where your company is an advertiser), have a book ghostwritten, and buy naming rights to a business school. Have your acolytes form a cult (Lean Six Sigma) with toxic group dynamics ("black belt" inquisitors and "green belt" minions vs everyone else).
This doesn't sound the world I live in. There's been insane innovation over the last 50 years. I don't think we can say that what you describe is common.
That's because businesses that innovate, or that have consistent high quality, don't operate like GE did under Jack Welch. Reverence for him and his supposed management principles is still commonplace, though not as much as in the 1990s.
He was dubbed "Neutron Jack" (a reference to the Neutron Bomb) for eliminating employees while leaving buildings intact. He was the main reason USA lost its manufacturing base and completely screwed up how Management was/is practiced.
The US commercial environment experienced a bit of a step change in 1971 - and, realistically, probably a lead up of pressure before that date.
A bit of systems thinking and it is probably not fair to say he is "the main reason". He was the first executive who figured out how to get best results in what at the time would have been a poorly understood new regulatory world that rewarded of financialisation.
I don't like to think in absolutes, so I was a little hyperbolic when I said he was responsible for the failure. You're probably right that it would have gradually happened anyway, but my limited understanding is he became the celebrity face to it that legitimized it and made it the defacto strategy. He is more than a little responsible for the mess we're in.
Seems somewhat legitimate, though I'd prefer more log graphs, linear scales can be misleading. Perhaps the Hakone Maru in 1968, the first TEU container ship (I think), was a harbinger.
A lot of that page builds a lot of point about specific time in order to sell the idea about dropping the unviable gold standard (in the form of Bretton-Woods system) as the real culprit.
