Interesting ideas. Im very interested in database ideas that bring new capabilities or better ways to acconplish old ones.
W.r.t. query speeds on your columnar storage engine, you will obviously have much better writes that row oriented storage engines. This limits your write capabilities though. Any effort you put into restoring write speeds necessitates an extra step to the maintain the columnar stores - which puts you back into the group of databases naintaining indices that you criticize above.
I think modern databases are bringing new ideas on how to accelerate both write and query speeds simultaneously with tradeoffs around CAP.
Although I have done many more benchmark testing against other databases for query speeds; I haven't noticed any significant speed degradation on writes.
Could you clarify what you mean by 'this limits your write capabilities'?
> W.r.t. query speeds on your columnar storage engine, you will obviously have much better writes that row oriented storage engines.
This should have said reads, not writes. Columnar storage takes significantly more effort to handle writes because it must do many more IOs across the different columns, potentially more de/compression cycles, etc.
This a really interesting and persuasive read for me. I've been thinking about this topic as part of brainstorming a simple design system and I had come to the conclusion that the inconsistency of not having icons for every menu item was a big annoyance. After seeing how descriptive the icons are in older menu examples compared to the abstract blobs in newer menus, I have to admit I might be wrong. At the very least, ensuring that the icons themselves are as illustrative as possible about the intended outcome of its selection is necessary.
It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so? In the age of natively storing documents in the cloud or copying to a USB drive, it seems like we might want more than one save menu or an appropriate icon for where the file resides on the single Save menu item. Microsoft Office has the Autosave toggle switch that serves some of this purpose, but it could definitely be better.
I also think about the Zune UI where sometimes a menu consisted only of the icons. How do you enable unique menu designs like Zune without icons for everything?
Check out how Blender’s entire UI (menus, buttons, hotkeys, pie menus, toolbar tools, context menus, etc) is built on a single abstraction: operators -- universal command objects that can be used in many contexts.
Every operator has:
Identifier: mesh.extrude_region_move
Label: human-readable string, like "Extrude Region"
Description: tooltip text, like "Extrude selected vertices, edges or faces along their normals"
Icon: optional enum from Blender’s built-in icon set, like ICON = 'MESH_EXTRUDE_REGION'
RNA properties: parameters / flags like direction, axis, booleans
Poll function: whether it is available in current context, like only enabled when a mesh is in edit mode
Execution logic: the actual command code
Blender’s designers generally follow these principles:
Operators always have labels. Icons are optional.
Most menu items use no icon by default.
Only well-established visual operations (cursor, transform tools, viewport shading modes, etc.) get icons.
Unlike macOS Tahoe’s vague "everything gets an icon" ideology, Blender uses icons when they convey meaning, but not when they’re decorative filler.
>It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so? In the age of natively storing documents in the cloud or copying to a USB drive, it seems like we might want more than one save menu or an appropriate icon for where the file resides on the single Save menu item.
It originated from when floppy disks were still widely used, yes.
Nowadays, people associate the icon of a floppy disk more with "saving locally" than the floppy itself. Changing it will just cause confusion.
Another example is how the icon for Database was chosen to resemble an old-timey stack of hard drive platters. Everyone knows what it means, even if your database isn't stored on HDDs, so there is no need to change it.
Even the telephone icon on your phone resembles an old-fashioned telephone horn, despite these getting less and less common.
> It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so?
It's a symbol, it could be a 7-pointed star and people would associate it with Save.
Even when you knew what a floppy disk was, why would you push that button? You haven't seen a floppy in years, don't have a floppy drive and don't want to create a floppy disk.
> It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so?
This is a pet peeve of mine and it feels like some cargo cult within the UI design "field". There's nothing wrong with the floppy icon. It's perfectly fine. Even if someone doesn't get it, the consistency of its use across apps is enough for its meaning to be clear, which is what really matters.
Before I read the blog post I would have agreed with you. It's pervasive, well understood, and the meaning is clear which you point out is what really matters.
But after reading the article I find myself asking if that's really true? I'm doubting it now. Certainly, the Floppy disk icon is clear to computer users who experienced at least a few years of the 90's or early 2000's. That's becoming less and less a percentage of computer users. For most users, that floppy disk has receded into being just a nonrepresentative shape associated to save.
I think it's that the blog post convinced me to reject nonrepresentative shapes as icons. You can't look at the extremely illustrative menu filled with icons that clearly describe window management actions or text formatting actions - where the icon itself conveys clearly, if abstractly, exactly how reality will look after you take the action - and tell me that a menu filled with random nonillustrative shapes has even a similar experience. I can't shake the idea that the menu icon needs to be more than just a logo or branding - it needs to be self-explaining.
The floppy disk did exactly the above when floppy disks were where the data was actually saved. But in 2025, we have to accept that it no longer illustrates anything. Today its just a nonrepresentative shape.
The human brain works with nonrepresentative shapes perfectly fine, otherwise companies wouldn't emphasize logos so much, often without even their actual name next to the logo.
Again, you don't even need to know what a floppy is or that it exists; its consistency and omnipresence, alongside the "Save" label most of the time, is enough to create meaning, such that most people will recognize it without the label.
I think local save is usually the floppy and cloud save is usually a cloud icon . The semantics change a bit when the app in question is a cloud app though.
I never got very far with this idea beyond coming up with it, but whe thinking about unfakable calculable characteristics that could be used for locality verificacion, i could only come up with latency as the key characteristic. Based on some geographical threshold distance the speed of light gives a reasonable estimate of how much latency there ought to be when communicating with someone. So if you could issue a challenge and time the response, you should know someone is local to you or not.
I think your point is that there is evidence that the intention of some or all of the developers and/or the organization as a whole is to make law enforcement more difficult. You go on to argue that this intention fundamentally alters how society, or at least law enforcement arms of government, should view this technology. Specifically, I take your argument to be that law enforcement should or will treat them as accomplices to some degree of the crimes they enable.
Don't forget the top half, either. In my experience, the people willing to sit down and fully do the work every time like GP are pretty rare compared to the lazy but lucky/charming/connected top and the lazy but unlucky/outsider bottom.
Keep being a real one, GP. It's so hard to not become jaded.
Manufacturing robotics is all about movement. All movement exists on a spectrum of difficulty and context needed to perform. For instance, welding the steel plates together in an empty and repeatable consistent 3d space is now on the lower end of difficulty. Navigating through a partially manufactured vehicle cab to install a complicated dash assembly requires a lot of context and is incredibly difficult for a robot to do.
The more we can bring down all the difficulty of all these processes, the more we can accelerate manufacturing locally.
That's at odds with everything I know about manufacturing robotics, having worked with people doing that work. The complexity of the environment is irrelevant because the robot is programmed to make a specific motion and to adjust that motion in predictable ways based on the appearance of specific features. That is by design, not because (or at least not just because) the robot is incapable of planning its own motion. The whole system is designed to be predictable instead of adaptable because that's what you need to do to do the same thing millions of times.
> The whole system is designed to be predictable instead of adaptable because that's what you need to do to do the same thing millions of times.
That final "millions" is the problem. Automation is great and easy when you will do the same thing millions of times. Sure it might cost half a million to program the robot (which itself cost half a million) - but that is $1.00 per part, and it goes down as you make more. When you are only building 10 though a million dollars is a lot of money and so you want humans - or robots that are "CAPABLE of plannings its own motion".
Costs have been going down. In high school I took the class on how to write g-code (I have one free period so I took shop for non-college bound kids for fun even though I was college bound - it was a great time that I highly recommend even though it was only for fun). These days almost everyone just uses their CAD/CAM and isn't even aware that the g-code is supposed to be a human readable programming language. (it probably isn't)
> Navigating through a partially manufactured vehicle cab to install a complicated dash assembly requires a lot of context and is incredibly difficult for a robot to do.
Not really. The robots are programmed by having a human manually guide it, so the robot itself doesn't really have to do any navigation - it just has to follow a predefined path.
Want to install different variants of dash components? Split it up into methods and have the robot return to a neutral position after each method. You're literally programming it.
W.r.t. query speeds on your columnar storage engine, you will obviously have much better writes that row oriented storage engines. This limits your write capabilities though. Any effort you put into restoring write speeds necessitates an extra step to the maintain the columnar stores - which puts you back into the group of databases naintaining indices that you criticize above.
I think modern databases are bringing new ideas on how to accelerate both write and query speeds simultaneously with tradeoffs around CAP.
reply