The sgi stuff was also engineering focused. The net result was it was not really that fast, powerful sure, but my understanding is the early consumer cards(voodoo) could run rings around them. The game cards did not have the z-buffer depth, fill rate, 3d texture support, line drawing, that sgi's had(cad features), but they could keep the frame rates high and had more features that made the games look pretty.
My personal favorite sgi from the mid 90's was the o2. It had a unified memory model so it was the slow red headed step child of the sgi ecosystem. But because of that unified memory you could effectively pack it with close to a gigabyte of texture memory, whatever the OS and app did not need. This was an obscene amount in 1996. For comparison the top of the line sgi desktop system at the time had 8 mb of texture memory. It does not hurt that the o2 was probably the best designed and engineered computer I have ever seen.
The amount of care they put into the little quality of life ui stuff is impressive. Something about how you can tell when the developers enjoy playing their game.
Youtube search is also weird in that it has a hard time finding something directly but will find it and put it it in the suggested videos feed after you have given up. 4 or 5 videos later. (shrugs) hell if I know.
But really, if I ever see a really good video I will download it. I try not to be too much of a digital horder, so it has to be really good. But their search has failed me enough times that it is worth it.
Teapot is pretty great, it's too bad there is close to zero room for real innovation in the spreadsheet domain. For the most part if it's not spreadsheeting how prophet Dan Bricklin envisioned, people don't want it.
See also: lotus improv
Actually... on that note I realized have never tried lotus improv.
> Teapot is pretty great, it's too bad there is close to zero room for real innovation in the spreadsheet domain.
One issue is that this is hard to do while still retaining backwards compatibility. Lotus Improv basically gave you no other choice, something that Excel The Next Version can't do. And I doubt that we're getting a third MS app, no Multiplan -> Excel -> NewSpreadsheetThingProbablyCalledCopilotAnyway.
I know a lot of people that don't even use Excel's tables, introduced almost 20 years ago. But instead they painstakingly recreate most of its built-in features. It's just an easy shortcut away, and has plenty of GUI support hidden in the ribbon morass, but it's not the default state…
As much as I like bsd I think the socket interface is their biggest failure, don't get me wrong, the socket interface is not bad, it is an amazing accomplishment that most of the internet is based on. The reason I regard it as a failure is because it is so close but not quite touching. A core unix idea is to have a single namespace registry and a simple universal api(open, seek, read, write, close) to access resources on this registry. and you can tell the bsd socket team was trying(like I said it's close) but they failed to close the loop and shipped an api that did not match the core unix api.
And for free, a rant, I think this is why Microsoft's registry is so bad. On paper it sounds great "a single place to put all your config" I could totally sell it. But in practice it is miserable to use. When proposed nobody said "we already have a hierarchical namespace where all our config can go and it already has pretty great tooling, lets just make it better" so they invented a custom one that required custom special access patterns and custom special tooling and custom special api's, and... it sort of sucks to use. I guess in their defense they were not fully onboard the idea that you could have one tree(they liked their many trees A: B: C:)
If you are doing it yourself shoot for the moon. If you want other people to work on your idea, then yeah you better be able to explain to those other people why the result would be worth it and why the approach is viable (or pay them not to care)
It is because the primary target for markdown is what would in any other formatting language be the source. Markdown has no source. It is guidelines for good looking plain text layout that when followed can be used to make a typeset document.
Everybody sort of knows it sucks as a formatting language. But we love it anyway. The benefit of being able to get a typeset document from a nice looking plaintext document is just too convenient. It is why specialized markdown editors make no sense to me. Why would you target something as shitty as markdown if you have a specialized editor? But really, if you at all care about the semantics of your document don't write it in markdown. But more importantly please don't kill the utility of markdown by adding semantics to it, all that noise just make the plain text look bad.
Unfortunately, the plain text does not look good, and does not offer good control of the typesetting. At least, nearly all markdown I see is almost unreadable in its “raw” state. I’d much rather read manually formatted, monospaced, text. That way, you can use asterisks as bullets, as footnote markers and as emphasis markers all at the same time, and anyone who is familiar with normal typographic conventions will understand what is what.
Not too long ago, I used to think that Markdown was the Bee‘s knees. But having been forced to write some documentation in plaintext, I learned that plaintext is significantly more readable than raw markdown.
I think one of Markdown‘s biggest sins is how it handles line breaks. Single line breaks being discarded in the output guarantees that your nicely formatted text will look worse when rendered. I understand there are use cases for this. But this and the „add a trailing space“ workaround are particularly terrible for code documentation.
> I think one of Markdown‘s biggest sins is how it handles line breaks. Single line breaks being discarded in the output guarantees that your nicely formatted text will look worse when rendered.
My experience has been the complete opposite. Markdown parsers that don’t discard single linebreaks (e.g. GitHub-flavored markdown) turn my nicely formatted text into a ragged mess of partially-filled lines. Or for narrow display widths, an alternating series of long and short lines.
Markdown parsers that correctly discard single linebreaks make sure that the source text (reflowed to fit a max number of characters per line) and the rendered text (reflowed to fit the display width per line) both look reasonable.
> Why would you target something as shitty as markdown if you have a specialized editor?
Your at-rest format allows you to use any tool to edit it.
The specialized editor becomes a preferred tool, but not the only tool nor the most important one. Markdown and it's ecosystem came before the editor.
I was trying to port a small program I wrote from postgres to a sqlite backend(mainly to make it easier to install) and was pleased to find out sqlite supported "on conflict" I was less pleased to find out that apperently I abuse CTE's to insert foreign keys all the time and sqlite was not happy doing that.
with thing_key as (
insert into item(key, description) values('thing', 'a thing') on conflict do nothing )
insert into user_note(uid, key, note) values (123, 'thing', 'I like this thing') on conflict (uid, thing) do update set note = 'I like this thing');
Email(smtp) is not a bad choice for messaging in space(or anywhere really) it is a well understood robust protocol designed in a time when all networks were slow and intermittent. Exactly what you need in space.
IMAP probably not so much, It depends too much on having a good network. unless the imap server is on the spaceship(heh, spaceSHIP, that is an optimistic term, but it is all we have, so going with it), I would not expect it to work all that well.
I am not very familiar with outlooks game, Historically my beef with with it and thunderbird was their local data store, I mean it was not strictly speaking bad, but I was like "we have this great Maildir spec, why are you using this propriety database that is prone to corruption, even if you don't like Maildir million files approach at least use sqlite"
Outlook when connected with exchange (which is probably the case, with corporate network email accounts connected) does not use SMTP nor IMAP, but Exchange RPC protocol, with underlying data model based on X.400 not SMTP. Can actually work pretty well but the implementation had been successfully eroded over last decade or more.
P.S. SMTP isn't well designed for slow and intermittent network protocols, it's designed so that you can bang it out on teletype by paying a grad student a twinkie and coffee and that should hopefully translate into simple implementation across different systems (only to relearn all the lessons of more complex ones, badly)
>Email(smtp) is not a bad choice for messaging in space
Email (Taylor UUCP g protocol) is a better choice for messaging in space. Resuming partial transmission is great! I used it up until ~2010 and it worked really great on some very, very crappy connections (modems, obviously, CDPD, phone tethering in spotty locations, bad WiFi setups)...
Hell every non wordpress software I manage also gets bombarded by wordpress bots.(not really, I am stretching the term to refer to wordpress attack attempts for dramatic purpose. But that still ends up being about 99% of my personal site traffic)
My personal favorite sgi from the mid 90's was the o2. It had a unified memory model so it was the slow red headed step child of the sgi ecosystem. But because of that unified memory you could effectively pack it with close to a gigabyte of texture memory, whatever the OS and app did not need. This was an obscene amount in 1996. For comparison the top of the line sgi desktop system at the time had 8 mb of texture memory. It does not hurt that the o2 was probably the best designed and engineered computer I have ever seen.
https://computers.popcorn.cx/sgi/o2/o2-05.jpg
https://computers.popcorn.cx/sgi/o2/
reply