Solar19

Right. Squarespace is a hosting provider and website builder that anyone should be able to use to build a website, typically a smaller scale website like a blog or a small to medium online store / e-commerce site. It's similar to Wix, Weebly, WordPress.com, and the website builders that some hosting providers offer.

Kubernetes is a tool large companies use to manage a large number of servers. Google invented it and open-sourced it so now it's free for anyone to use. It's not something people would use for a single website unless it was a huge website that required lots of servers, like FoxNews.com or something.

This would seem to be a private problem. If people choose to park their money with a non-transparent, unaudited random crypto startup, that's their decision and their problem. I'm not interested in paying for "regulators" in such cases.

Good work on Redis. Ruby, however, strikes me as pretty fragile. They can't get it running on Windows, officially, and the third-party Windows installer is hit or miss. Ruby also seems to depend on a specific compiler, gcc. I wouldn't be surprised if it has trouble on ARM.

For a time Intel had PCs on a stick – it was like a large flash thumb drive, with a Celeron or something. (Maybe they still offer these.)

Are there any thumb drive ARM computers? (Preferably with 64-bit ARMv8 processors to match emerging server platforms.) With pluggable ARM mini-computers it might be easy to develop for ARM.

Raspberry Pi would be interesting, but they have old 32-bit processors and I'm not sure how well they interface with a normal computer. Servers are using 64-bit ARMv8.

Maybe smartphones would work as pluggable mini-computers? I heard that OnePlus devices were explicitly root-friendly, but I've never tried it.

Nice. This reminds me of some old patents I like for optical keyboards, e.g. https://patents.google.com/patent/US4379968A

Though real optical would require optical equipment in the desktop's or laptop's chassis or motherboard, and OS support, since it wouldn't be USB at any stage.

Any data on HTTP/3 performance? I don't see it in the book. There's the general claim that it's faster/lower latency, but there are no numbers behind that claim -- last time I checked QUIC's performance benefits were incredibly slight.

Me too. The diabetes angle is interesting – I hadn't thought of that.

Oh, I'm not a Trump voter if that's what you meant. I have plenty of issues with Trump, especially his Twitter behavior. I like some of the bills he's signed, and what he might achieve in opening foreign markets to American exports, esp. China.

Right. I forgot about those.

It's something that has been researched, but not deployed. It would implement GC memory tagging in the CPU or even the memory controller. Google Scholar should produce some good hits.

This was the research that led to WSL.

Nice. Does Visual Studio support the level or version of OpenMP used in this code? (see the pragma)

My experience is different. As a social scientist, I've never seen hatred like leftist hatred. I'm exposed to the academic left, which is seething with hatred and intolerance. As far as the mainstream, non-academic left, boy they sure hate Trump – and anyone who supports him.

And before Trump, leftists already had a pretty intense hatred of Republicans/conservatives, and libertarians to the extent they know about them. America is extremely partisan, and the two major camps tend to strongly dislike each other, sometimes popping out as real hatred. Research shows that conservatives tend to know more about leftist positions than leftists know about conservative positions, so that suggests that leftists may be operating with more emotion and less information.

(And when I use the word "hate", I mean hate as defined in common dictionaries. The left has infamously co-opted the word to refer to any negative appraisal or feeling about a person or group of persons experienced or expressed by a non-lefist. I'm sticking to hate as extreme animus.)

You really only see this coming from the right / Fox News?

Whenever we see an apparent monopoly or a confusingly high profit margin, we should immediately look for barriers to entry. Situations like this are usually explained by the existence of a racket with government-enforced barriers to entry.

Optometry is a licensure racket with strong legal barriers to entry. The sale of glasses is ostensibly a separate business without the same barriers, but I suspect it rides on the coattails of optometry's racket. I think there's an inertia tie between the eye exam and the purchase of glasses.

The cleanest way to end this nonsense is to break the optometry licensure racket. Think about what optometrists actually do. Think about all your eye exams and the whole "1 or 2" procedure as they flip through lenses. Honestly, most adults could probably do that job and produce a correct prescription after maybe a week's training. I'm not saying they're inherently bad people or anything, and I like my optometrist, but it's a racket just like realtors, lawyers, and other guilds that use the law to prop up their prices and reduce competition.

There's at least one startup out there that wanted to do eye exams through a specially designed web app. Expect the optometry racket to lobby hard against this, just like taxi rackets tried to stop Uber. And there ought to be companies offering cheap glasses online any second now...

I have several somewhat orthogonal thoughts on this:

1. This is exactly what I've feared and suspected about JPEG-XR, webp, and JPEG-2000 (which Safari ever so quietly supports). I especially wondered about JPEG-XR after reading how Microsoft had done some great things with GPU-based hardware acceleration for JPEG decoding in IE11: https://blogs.msdn.microsoft.com/ie/2013/09/12/using-hardwar...

I was puzzled by the fact that they never mention JPEG-XR and have never published a similar post about hardware acceleration for the more modern format. They've been incredibly lazy and unfocused on XR for years. It's effectively dead now.

2. The author of the don't use it post keeps saying it gets "software decoded". This implies that this is unusual. But it isn't. Does he think JPEGs are not software decoded? They are in Firefox, and probably every other browser but IE11 and Edge. Someone correct me if I'm wrong. Browser makers have been surprisingly inert on using GPUs for image decoding. libjpeg-turbo is used by Chrome and Firefox, and possibly Safari. It's pure CPU, albeit with some SIMD. That's "software decoding". Hardware acceleration normally means GPU, or a fixed function unit/ASIC like you see for some video codecs.

3. One percent? This was all about a -1% drop in some metric? What's the error margin?

4. He implies that there's a lot of JS in this SPA. This seems like a possible confound that won't necessarily apply to rigorous web developers who don't overload on JS (who are admittedly extremely rare in 2019). Sure, they showed that XR was using more CPU, but so do all post-JPEG formats.

5. Which leads to my last point. What about webp? He strangely never mentions it. It's like only JPEG and XR exist. webp performs very poorly in CPU efficiency compared to JPEG. What are trivago and Cloudinary seeing on that front? Is webp less taxing than XR?

It doesn't matter. It will look the same.

I see your point on beginners and formally verified systems code. However, I'm imagining a somewhat different universe.

Formally verified systems code is a nightmare right now. It's almost impossible, and hardly anyone does it for pay. Obscure tools like Isabelle or Coq are needed. People try to shoehorn formal verification onto C, which is a terrible lack of imagination and use of time. Maybe it's easier with Ada or Haskell or something – not sure.

I want a revolution. I want a whole suite of new, clean-sheet programming languages that are the result of furiously brilliant multifaceted design. I want formal verification to be easy, or easier, and baked in to systems languages. I want new operating systems built in these new languages. Some of the dissenters in this thread are assuming that building a new operating system involves firing up your C compiler of choice, and dismiss the whole enterprise as a multiyear bug-ridden nightmare ("never rewrite!" they say) – that is definitely not what I'm thinking about. To hell with C.

It's time to move forward. This is supposed to be a technology industry. It's supposed to be about technological progress. PL design is not progressing. It's awful and it repels newcomers, especially women. We need to drop all these assumptions about programming being done in primitive plain text editors on primitive steampunk Unix-like OSes using primitive command line interfaces with languages as intractable as Linear A. That whole package, which is often what people are introduced to in intro CS courses, is about the worst way to introduce people to the power and wonder of computing that we could have devised.

We need to think more deeply about how to handle and represent various abstractions, functions, and imperative code. Functions should not have bizarre void statements and empty parens, for example. That's so unintuitive. At this point, functions should probably be like equation editors. The pure mathematical function in its normal book representation could be what we see in our IDEs. Visual/graphical programming never really got out of the gate because they just converted code to boxes and arrows. There's an opportunity there to rethink that whole approach.

But if we don't get people interested in programming, if we don't make it less terrible, they never get to systems work. And systems work should not look like Rust or C++. There is no reason why a modern IDE or even text editor should need curly braces or semicolons to understand or compile code at this point in the history of the software industry. Text is a solved problem. Indentation and spacing and line breaks are all trivial to parse. Colors could be semantic. Emoji could be code. Icons, badges like we see for build passing/failing could also be used as code. There's a lot we could do to make programming make a lot more sense.

One of the reasons I want to get more women into programming is that I think they'll be better programmers than men in some respects. Think of archetypes or stereotypes like Hermione vs Harry Potter, Lisa Simpson vs Bart, Wendy Testaburger vs Stan, Kim Wexler vs Jimmy McGill. There is anecdotal, cultural, and scientific evidence to suggest that women – or some subset of women – are more responsible and meticulous than some of the male personality types we often see in tech.

I'll have more on this this week in my report on Medium on Google's firing of developer James Damore for citing well-established social and personality psychology research (my field) on sex differences. I get into some of the reasons programming is generally terrible, and why women might be disproportionately repelled by it. Dart is my victim/example in this report, but I think pretty much all languages are awful. (Eiffel and F# should be the worst case, the bare minimum starting points...)

I think it's actually much easier now to get people on a new OS then it was a decade ago, or in the 90s, or the 80s. The web is so centric that a new OS with a great browser has won half the battle (I could write five pages on how massively better a browser could be than Chrome, Edge, Firefox, Safari, Opera, etc. and I love Firefox and Opera and Vivaldi and Brave.)

ChromeOS has partly proved the point, especially among college students and younger. Anyway, a serious effort at a new OS, a whole new stack, along with a new office suite and other applications, could succeed with the right (large) team and funding. People aren't very loyal to Microsoft – they're not loved. And Apple users have no idea how much better computers could be, but they would if someone showed them.

So I'm coming at this from a social science perspective. Why did I say "not Rust"? I'm working on a research program to get at what happens when people engage with programming for the first time, aspects of language design that attract or repel learners, and as sort of a related offshoot, why smart women are so disproportionately less interested in programming.

One of my working hypotheses is that programming is terrible. More precisely, the majority of (smart) people who are introduced to programming have a terrible experience and do not pursue it. I think many smart people walk away thinking that it's stupid – that the design and workings of prevailing programming languages are absurd, tedious, and nonsensical. (Note that most men aren't interested in a programming career either. So it's not just smart women.)

Most intro to CS or programming courses seem to use Java these days. That's an unfortunate choice. To veteran programmers, Rust likely seems very different from other languages. Its default memory safety, ownership and borrowship and other features are innovative. (Though the amazing performance of Go's garbage collector seems to weaken the case for Rust's approach somewhat.) However, to new learners, I'm pretty sure Rust will be awful. It's fully traditional in its mass of punctuation noise, just saturated with bizarre (to outsiders) curly braces and semicolons. It also has, in my opinion, extremely unintuitive syntax. I see it as somewhat worse than Java in that respect.

Honestly, Rust is brilliant in more ways than one. I just think they punted on syntax and punctuation noise. I think our timeline is just weird and tragic when it comes to programming languages. They're almost all terrible and just so poorly designed. There's hardly any real scientific research on PL design from a human factors perspective, and what research there is is not applied by PL designers. PLs are just the result of some dude's preferences, and no one seems to be thinking outside of the box when it comes to PL design. In the end, to really make progress in computing and programming, we might need outsiders and non-programmers to design PLs. I'll say that the now-canceled Eve programming language project is a notable exception to the consistent horribleness of modern PLs. We need a few dozen Chris Grangers.

Good point. I forgot to mention that. I don't know if they're going for Instant Computing though. Are they?

Yes, I like them a lot. A formally verified OS should be the standard these days (and formally verified compilers). But for that to be so, we'll need new programming languages (not Rust) and toolchains I guess.

This is interesting, and to some extent, expected. I'd expect that emulating one OS on top of another is going to have performance challenges and constraints in general.

But the deep dive into aspects of Windows and Linux I/O reminded me that I'd love to see a new generation of clean sheet operating systems. Not another Unix-like OS. Not Windows. Something actually new and awesome. It's been a long time since Unix/BSD, Linux, and Windows NT/XP were introduced.

A few years ago, Microsoft developed a new operating system called Midori, but sadly they killed it. MS, Apple, and Google are each sitting on Carl Sagan money – billions and billions in cash. Would it hurt MS to spend a billion to build an awesome, clean-sheet OS? They could still support and update Windows 10 for as many years as they deemed optimal for their business, while also offering the new OS.

Would it cost more than a billion dollars to assemble an elite team of a few hundred people to build a new OS? Would Apple, Microsoft, or Google notice the billion dollar cost? Or even two billion?

If you think there's no point in a new OS, oh I think there's a lot of room for improvement right now. For one thing, we really ought to have Instant Computing in 2018. Just about everything we do on a computer should be instant, like 200 ms, maybe 100 ms. Opening an application and having it be fully ready for further action should be instant. Everything we do in an application should be instant, except for things like video transcoding or compressing a 1 GiB folder. OSes today are way, way too slow, which comes back to the file access performance issue on Windows. Even a Mac using a PCIe SSD fails to be instant for all sorts of tasks. They're all too damn slow.

We also need a fundamentally new security model. There's no way data should be leaving a user's computer as freely and opaquely as is the case now with all consumer OSes. Users should have much more control and insight into data leaving their machine. A good OS should also differentiate actual human users from software – the user model on nix is inadequate. Computers should be able to know when an action or authorization was physically committed by a human. That's just basic, and we don't have it. And I'm just scratching the surface of how much better security could be on general purpose OSes. There's so much more we could do.

Thanks, that helps. By the way, why are they time stamped at the beginning, or at all?

Forgive my ignorance. I'm more of a social scientist than a programmer. Questions:

1. Why not go for 16-character strings (instead of 26 or 36), with each character representing 8 bits?

Sure, you'd need 256 possible characters, but it's almost 2019 and Unicode has been with us for decades now. Surely we could be more cosmopolitan than Americentric ASCII and curate 256 characters for an 8-bit encoding?

With a 16-byte string, we could compare and process strings much faster, particularly with SIMD instructions like Intel/AMD's SSE 4.2 string comparison instructions. They're optimized for 16-byte strings and were introduced many years ago in the Nehalem architecture. That's a couple of generations before Sandy Bridge, so any server today is going to support it.

2. What does it mean to be "user-friendly" when it comes to these sorts of IDs? What are some scenarios where users interact with them or communicate or share them with someone or some authority? Crockford wanted his 32 character set to be easy to convey on a telephone, which seems like an expiring use case today. It seems like we should be able to use all sorts of non-ASCII characters now, without resorting to the Unicode Klingon or Tengwar blocks. Do we really need to be able to pronounce them all like Crockford anticipated?

NOTE: Unicode characters beyond the Basic Latin block take two or more bytes each, so we wouldn't be able to use them encoded as Unicode. What I'm advocating is a 256 character set with each character encoded in one byte, strictly for the purposes of generating these sorts of unique IDs represented by compact 16-character strings. Call it Duarte's Base256. All these other BaseN systems seem orthogonal to character encodings, or they just assume ASCII. I guess my idea would require both a character set and an encoding scheme. The latter would be similar to ISO/IEC 8859-15 and Windows 1252, but more complete with 256 printable characters. A lot of them could probably be emoji.

How good or terrible is this idea?

Crockford also excludes the letter U, because of potential profanity, which I find incredibly odd. He's afraid of a rare FU embedded somewhere in an ID? Why would we care about that?

People should be free to live their lives.

No, I just uninstalled the FB and Messenger apps from my phone when I read that the app was getting phone call data. And because they've been censoring non-leftist voices. I only use FB on browsers on desktop until I finally migrate to something better. I've started cross-posting on Gab.

How is it Rust project if it's installed via Node?

How would it work otherwise? How would we automate consent from the relevant webmaster, website owner, etc? It seems like we wouldn't be able to successful communicate with the principal in many or most cases.

I've thought of something vaguely similar – documenting website behavior and optimization opportunities without the involvement of publishers. It would be nice to have a known online resource/repository for this, kind of like the security vulnerability communication website that I can't remember at the moment.