Looks great, there's a very defined use-case and the video is very clear.
Does anyone know of any other similar piece of software, preferably open source, that allows for complete customization? I have another use-case different from the one on this product and I could use some advice.
There are some non-ingestion (requires you to use the frontend) headless CMS options that may also fill this space ( https://headlesscms.org/ ) if you tilt your head and squint.
This space seems to be growing, primarily on the API side, I imagine the frontend side may be next.
Currently my favorite is PostgREST and custom VueJS forms (using Quasar for "rapid dev"), but requires lots of 'bring your own' work.
Hey there - We (seekwell [0]) let you create highly customizable Forms [1] and editable tables [2] which you can add to a dashboard and expose to non-technical people on your team. We have a company with over 100 people in sales and operations using this daily. Supports Postgres, MySQL, Snowflake and SQL Server.
Thanks for that! I set out to make a simple solution to a real problem that I had experienced on a lot of web development projects. I hope it's useful to others as well.
I looked around for a long time for a similar tool -- open source or otherwise -- and I never found something exactly like what I had in my head. So I decided to built it myself.
I'd be very interested in hear about your "other different use-case" ... I'm very open to making enhancements and adding new features driven by specific user's needs. If you'd like to chat about what you're trying to build, please drop me a line and maybe we can make something happen!
I found it surprisingly hard to get access to the primitives mentioned in the intro, on a modern pc. How does one draw a pixel on a specific coordinate in a modern OS?
SDL is generally the most painless way to get a framebuffer you can draw in, cross-platform, and it also handles creating windows, reading input and playing sounds if you want to. You can use it from C and pretty much any other language has bindings. Also any GUI toolkit will have a widget that is a blank canvas (Qt and Wx both do, GTK should as well, but I haven't used it much). Or you can write in javascript and use canvas.
the best/easiest way is still use opengl/directx/etc but draw your texture in software, and then draw the texture full screen.
This is the approach I used to teach software rendering in gameswithgo.org we make a putpixel function as in the old days, and use it to build up a texture, which we draw each frame. The texture becomes what used to be the framebuffer.
Copying the entire framebuffer over the PCI bus makes me sad, though it's obviously way faster than when you could memory-map the framebuffer. These days you can't map texture objects in memory because texture storage on GPUs is its own black magic and textures are not stored as simple linear framebuffers. It would be fun to restrict yourself to a well-documented architecture, e.g. give everyone a cheap intel-based notebook and write out commands directly for the graphics chip. I guess while fun that would teach more about doing low-level hardware access than graphics themselves.
And while on the topic of changing hardware forcing us to change our algorithms, I wonder if teaching scanline rendering is even worth it these days. Every CPU supports SIMD and a SIMD-optimised software rasteriser is a very different beast than the classic scanline triangle rasterisers of old.
Probably the fastest software rasteriser for modern CPUs is OpenSWR [0], written by Intel mostly to keep themselves relevant in the data visualisation space until GPUs eat HPCs (GPUs still can't help you when your dataset is measured in hundreds of gigabytes of graphics data), but it scales perfectly fine down to desktop CPUs. The code for it is in the Mesa tree [1]. I wish I could explain exactly how it works, but it's a pretty big beast and I haven't had the time to read and understand all of it. Intel gave a presentation on it at the HPC developers conference back in 2015 [2]
Here's the sample code I pass around for doing that. It's a minimal example using SDL. AFAICT, it's pretty much the fastest way to get graphics from the CPU RAM to the screen.
Not quite "writing a pixel to the screen", but to play around, you can use a <canvas> tag in HTML, like my demos do; you can use SDL, as another poster commented; or you can write some trivial code to write a PPM file to disk (or use something like libpng) to create image files on disk.
A lot of proof-of-concept code renders to memory (and putpixel becomes screen[y*width+x]=pixel) and then saves the memory to a graphics file. If you've already been motivated to work with graphics you probably already know how to save a PNG file. If you have ImageMagick you can even render to a raw, uncompressed, non-standard graphics file and describe the format of the file in the 'display' command when you want to view the file. Also standard formats like BMP and TGA can be pretty easy to use without a library.
It never was that easy (hang on, were there BIOS functions for that?). Anything that requires drilling down to draw a dot is too slow anyway. Obviously blitting an offscreen bitmap just leaves you the problem of dealing with pitch.
It was even more exciting dealing with rendering high resolution images with only a single line of bitmap. #thegoodolddays
Even though that phrase password is 16 characters long, it has the same entropy as a 9-10 letter long alphanumeric random password (according to KeePass' generator). I agree that it's easier to recall, but it's half as secure as a properly random 16 character one.
I've used Debian's xkcdpass to generat 50 sets of 100 million passwords, then then checked for duplicates. The algorithm uses six words and a large dictionary, but otherwise resembles the xkcd original.
There were no duplicates in any of the 50 sets. (About a week's runtime on a fairly modest Intel processor.)
Given that 100m accounts is a fair fraction of the world's active computer users, that's a pretty good start.
(There are further reasons for finding passwords alone insufficient for security, but at least these are strong, and yet potentially memorable, passwords.)
