Hacker Newsnew | past | comments | ask | show | jobs | submit | somat's commentslogin

A nice joke but... this is an sgi, they pretty much invented accelerated graphics. Original glquake used minigl which was GL cut down and neutered to fit within the glide api, these guys invented and their systems could run the full GL. There actually was a very nice accelerated port of Quake on the demo disks included with the system.

It's already done as Quake it's libre source and if the GLIDE headers for SGI match the ones of the 3DFX ones from the Linux implementation it would be just a matter of path setting and a few ifdefs.

As someone with a room full of SGI equipment which already runs Quake (and Doom, and Mektar and Tranquility), I can only say: this port to Voodoo on Irix needs to be done. ;)

Soon :) Just got MesaFX working with the Voodoo card. Planning to use that as a miniGL replacement.

Awesome. Can't wait to see your progress.

What other neat hardware support might you add in the future?


Well, Voodoo2 is next for sure. As soon as I have a machine in which it actually fits.

Just pick any VooDoo supported source port (old enough, from gcc 3.4 days) it might compile as is with very few changes.

EDIT: all of them use MiniGL, damn....


There isn’t a Glide version of Quake. John Carmack didn’t want to do endless vendor specific API variants of Quake after an early Rendition Verite port burned him, so just released Glquake and said vendors should support standard APIs.

3DFX had a mantra of “no CAD” so didn’t support OpenGl, as they saw it as a primarily aimed at running CAD software etc. So therefore they had to come up with the somewhat hacky MiniGL to implement enough of OpenGL to get Quake to actually run.


That's because CAD graphics for games where a very different beast. NV Quadro cards would maintain far more objects being rendered but with slower FPS' as a CAD rendering wouldn't requiere real time FX with constant changes everywhere. If you have a look at GLIDE games the effects somehow look 'prettier' and the lights more 'alive'.

/u/sdz-mods - the person doing the 3DFX port to Irix - reported just now that they got MesaFX up and running and that'll serve as the basis of a "MiniGL" to get the port done. ;) So, there is hope!

Now I am curious, how does the voodoo 1 compare with the native o2 gfx?

The o2 used a unified memory scheme so it's graphics were never as fast as it's big brother the octane's impact graphics but because of the unified memory it was a texture power house in comparison, close to a GB of texture memory in 1996 is mind blowing, in comparison the ocatane's impact graphics had 4 mb of texture memory and if you payed out the big bucks for a max impact with double the memory(which was the size of a large motherboard)... you still only got 4mb because the extra memory was basicly sli. and a graphics board that had the reputation of desoldering it's own memory off.


Quake 2 runs a bit iffy on an O2, but runs fine on PC with a Voodoo 1

I wonder if it's optimized for it. Quick! Someone send Fabien an O2 before he finishes his Quake book!

It makes me think of ipsec, ipsec was originally intended to be used sort of the the same as we use tls today, but application independent. when making a connection to a random remote machine the os would see if it could spool up a ipsec sa. No changes to a user program would be needed. But while they were faffing about trying to overcomplicate ipsec ssl came along and stole it's lunch money.

This application of ipsec was never used and barely implemented. Today getting it to make ad-hoc connections is a tricky untested edge case and ipsec was regulated to dedicated tunnels. Where everyone hates it because it is too tricky to get the parameters aligned.

There is definitely a case to be made that it is right and proper that secure connections are handled in the application(tls), But sometimes I like to think of how it could have been. where all applications get a secure connection whether they want one or not.

As a useless dangling side thought, an additional piece would be needed for ad-hoc ipsec that as far as I know was never implemented, a way to notify the OS that this connection must be encrypted(a socket option? SO_ENC?). This is most of the case for encrypted connections being the duty of the application.


here is a great video documentary on the m-15

https://www.youtube.com/watch?v=ZlyO9cJ8hiQ (Alexander the ok: PZL Mielec M-15: One of the Aircraft of All Time)


If we are doing a survey, you missed one of the most interesting ones

teapot https://www.syntax-k.de/projekte/teapot/


ulimit?

or more probably the c api setrlimit(2)


That does not cap memory per query, which should be implemented by postgres explicitly to capture only the memory that really counts towards "the query" (fine-grained memory limits; ulimit is not that).

Be careful with the setrlimit/ulimit API family, generally it doesn't do what you want. You can limit virtual memory (but... why?) or specific segments like stack, etc. There is also RLIMIT_RSS which sounds like what you'd want, but alas:

    RLIMIT_RSS
        This is a limit (in bytes) on the process's resident set (the number of virtual pages resident in RAM).  This limit has effect only in Linux 2.4.x,  x  <  3 and there affects only calls to madvise(2) specifying MADV_WILLNEED.
I also disagree with the conclusion "No hardware can compensate for a query gone wrong". There are concepts like 'quality of service' and 'fairness' which PG has chosen to not implement.

"you catch more flies with honey than vinegar."

The fun part about that truism is that when actually tried. You find out the flies love vinager, Far more than honey, something about the smell?

It could be said the other way around, which is also true, the best way to get someone to respond is not a well structured question but by being wrong.


Yes, I had that one xkcd in mind as I wrote that :)

I want to mention teapot. First an apology, it's not actually a good match for for question, sure, it's a curses spreadsheet, but it was made by someone who thought about the fundamentals of the problem a little too much. So it is probably a little too weird for someone who just wants to spreadsheet as Dan Bricklin intended.

https://www.syntax-k.de/projekte/teapot/

In short cell address are normalized @(1,2,3) instead of A1 or r1c1. real references so address rewriting hacks($A$1) are not needed. formula references so you can use a single master formula, and clocked expressions which allow circular dependencies/simulation.

Probably a little too different for casual use but worth taking a look at, if nothing else to challenge your ideas of what a spreadsheet has to be.

While looking up the website I found a rewrite in rust, which is cool I guess, someone is keeping the dream alive, I will leave a link to that as well.

https://github.com/veridit/teapot


It's weird but visidata is my favorite spreadsheet.

"But... visidata is not a spreadsheet"

I know, that's what makes it so weird.

On contemplation, I think I grew dissatisfied with the normal spreadsheet data model, I wanted something bettered structured than the "it's a big bag of cells" that spreadsheets present, I wanted row security. The best I found was the relational database. I currently use a local postgres db for most things I would have used a spreadsheet for. The interfaces sort of suck in comparison but at least I have sane data structures.


Microsoft access was always a moderately mediocre database but it was also always an amazing spreadsheet for so many use cases.

I am not sure if I know what I am talking about or if it counts in this scenario but constraint solvers come to mind. I am mainly familiar with them in a CAD context so I am struggling to think of a use for them in a spreadsheet context. But I think being able to say given these endpoints find me some values that fit could be a very valuable tool.

But like I said I am not sure that I know what I am talking about and I may be confusing backwards calculation with algebraic engines. I would love for algebra solvers to be a first class object in more languages.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: