That's quite expensive. Most systems that need this sort of data will instead implement some form of audit log or audit table. Which is still quite expensive.
At the record level, I've seldom seen more than an add timestamp, and add user id, a last change timestamp, and a last change user id. Even then, it covers any change to the whole row, not every field. It's still relatively expensive.
Yeah, this seemed like a very long way to say, "Our RDBMS has system catalogs," as if it's 1987.
But then, they're also doing JOINs with the USING clause, which seems like one of those things that everybody tries... until they hit one of the several reasons not to use them, and then they go back to the ON clause which is explicit and concrete and works great in all cases.
Personally, I'd like to hear more about the claims made about Snowflake IDs.
I'm ashamed to say that despite using SQL from the late 1980s, and as someone that likes reading manuals and text books, I'd never come across USING. Probably a bit late for me now to use it (or not) :-(
I've used SQL for around a decade and also never came across it. I'm maintaining SQL code with hundreds if not thousands of basic primary key joins and this could make those queries way more concise. Now I want to know the reasons for not using USING!
First, you need to be aware of the implicit disambiguration. When you join with USING, you are introducing a hidden column that represents both sides. This is typically what you want - but it can bite you.
Consider this PostgreSQL example:
CREATE TABLE foo (x INT);
INSERT INTO foo VALUeS (1);
CREATE TABLE bar (x FLOAT);
INSERT INTO bar VALUES (1);
SELECT pg_typeof(x) FROM foo JOIN bar USING (x);
The type of x is is double, - because x was implicitly upcast as we can see with EXPLAIN:
Arguably, you should never be joining on keys of different types. It just bad design. But you don't always get that choice if someone else made the data model for you.
It also means that this actually works:
CREATE TABLE foo (x INT);
INSERT INTO foo VALUeS (1);
CREATE TABLE bar (x INT);
INSERT INTO bar VALUES (1);
CREATE TABLE baz (x INT);
INSERT INTO baz VALUES (1);
SELECT \*
FROM foo
JOIN bar USING (x)
JOIN baz USING (x);
Which might not be what you expected :-)
If you are both the data modeller and the query writer - I have not been able to come up with a reason for not USING.
Thanks for the reply. The use case I have in mind is joining onto an INT primary key using a foreign key column of another table. This alone would remove a massive amount of boilerplate code.
@da_chicken: You can read more about Snowflake ID in the Wiki page linked in the article.
The short story:
They are bit like UUID in that you can generate them across a system in a distributed way without coordination. Unlike UUID they are only 64-bit.
The first bits of the snowflake ID are structured in such a way that the values end up roughly sequentially ordered on disk. That makes them great for large tables where you need to locate specific values (such a those that store query information).
No, that's like calling Amazon a social media platform.
YouTube is a content delivery platform that has social media features. You can tell because if you shut off all the comments, people still visit the site in droves. But if you shut off the videos and left the comments then nobody would visit the site at all.
Now, it's possible that YouTube doesn't realize that, but I think they're just unwilling to make any changes at all if it doesn't give them any competitive advantages.
Yep. Gabe was right when he said it and he's still right now. Valve knows the product is service. This is why Epic Games Store and Microsoft Store have such a hard time. Good games come and go, but good service is good service.
And now, Valve is pushing to leave Windows, because they see which way the wind blows in Redmond. They don't want to be leashed to Microsoft in 2026 anymore than Microsoft wanted to be leashed to IBM in 1986.
Protocol multiplexing/demultiplexing is a feature of software like sslh, nginx, and HAProxy exist, and they don't need to listen on multiple ports to speak multiple protocols or connect multiple services. Many advanced reverse proxies can do this with stream sniffing of some flavor.
People already do actually run everything through port 443 simultaneously.
Protocol multiplexing exists. But you will have to agree on a single protocol, which I view as impossible since different applications have different requirements.
If you route all your traffic through https that comes with all the upsides, for example the security layer (ssl). But also the downsides of for example overhead of headers. Currently we have an overarching (network layer) protocol, it is called IP. It divides the traffic into different ports at the host, these ports speak different protocols. If you move the multiplexing higher up the OSI stack, you are violating the principles of separation and making your stack less flexible, you are mixing OSI layers 4: transport up to 6: Presentation. Conflicting these layers can lead to big problems as this includes things like the Transport layer, for example the difference between udp/tcp is included there.
The beauty of the network stack is that there are certain layers that separate responsibility. This allows the stack to apply to wildly different scenarios. However I do agree that there should be no filtering applied on behalf of the customers.
> Protocol multiplexing exists. But you will have to agree on a single protocol
I may be misunderstanding your message here, but the requirement to agree on a single protocol isn't true when you're using multiplexing. I think you're confusing tunneling with multiplexing.
With multiplexing, you have multiple protocols listening on a single port. The multiplexer server sniffs the first few bytes of what the client sends to determine what protocol is being used, then decides which back-end to forward the connection to.
Neither the client nor the final back-end need to be aware that multiplexing is happening, and likely aren't.
Through this, you can use both HTTPS and Telnet on port 443 without the Telnet client needing to have any changes done.
That's my question. Why is there infrastructure that has open access to port 23 on the Internet. That shouldn't be a problem that the service provider has to solve, but it should absolutely be illegal for whomever is in charge of managing the service or providing equipment to the people managing the service. That is like selling a car without seatbelts.
We are beyond the point where not putting infrastructure equipment behind a firewall should result in a fine. It's beyond the point that this is negligence.
I've lived in Michigan for about the same length of time, and even with the terrible service our current power companies are providing the only time I've lost power for more than a few minutes during the winter has been after an ice storm.
Edit has not shipped with Windows since Win9x -- which is to say, it hasn't shipped since Windows required DOS -- and what you linked is an homage project, not the same program.
And you know what else was included in versions of MS-DOS that shipped with Win9x? Edlin. The editor so basic most people can't figure out how to use it.
It's a cost vs benefit. As long as the cost of such blatant violation of security principles doesn't outweight the benefit of focusing on something else, nothing is done.
I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.
Because that's not how corporate maths works. The comparison is not "what is the cost of this vs our current revenue?" The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?"
Will fixing this issue bring in more revenue than ignoring it and building a new feature? Or fixing a different issue? If the answer is "no" then the answer is that it doesn't get fixed.
> The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?"
I don't agree with this, because it pre-supposes that there's a limited number of engineers available. The question isn't "shall I pull engineer X off project Y so that he can fix security bugs?", it's "shall I hire an additional engineer to fix security bugs?". The comment above mine suggests the answer to that question is "no, because it's too expensive to do that compared to just paying to clean up security breaches after they happen", which is what I was questioning in my first comment.
It doesn't matter: the equation is exactly the same. Why would you hire someone to work on a bug fix or security fix when you could hire that same person and have them work on something even more valuable again?
Now there's a related problem in the premise: it pre-supposes that the company has an unlimited amount of valuable work to be done. If that were the case, all companies would simply expand their workforce as much as possible all the time, only constrained by money running out (which itself would be an exponential increase since "valuable" work presumably leads to more money in future). In reality, companies do not prioritise expansion above all else. In fact any time a company pays a dividend to its shareholders, or otherwise refrains from spending cash reserves on new hires, it's recognising that it cannot invest profits in an effective way into its labour force.
When framed correctly (there's effectively an unlimited labour supply for most companies, and effectively a limited demand for staff) then the question becomes "shall we hire an engineer to fix security bugs when we don't need an engineer for anything else?".
> it pre-supposes that the company has an unlimited amount of valuable work to be done.
In effect, there is, yes. At the very least, there’s more high value work that most companies can do than there are engineers to do said work. There’s a reason literally every leadership course teaches you how to say “no” over and over again.
First they have to hire a developer with knowledge of how to do this right, as they might not even have one. Which could easily eat 10k+ of dev time as hiring good people takes a lot of time.
You could probably take any user at random from this discussion alone and they'd have the knowledge needed to make the switch from http to https. I'm certain that AMD has all the knowledge they need right now, but even more certain that it wouldn't be hard to hire someone new who does as well
Ok, but this ultimately just comes down to a debate over the amount of the cost. The principle is the same. Even if we double or triple the cost, it's a drop in the ocean for a company like AMD.
I didn't say I don't believe it happens. I'm saying I don't believe it's a based on a cost benefit analysis. I.e. that in a multi-billion dollar company someone consciously ran the numbers and decided "it's cheaper for us to pay to clean up the mess if there's a security breach than it is to hire someone to fix security bugs". The cost of the latter is too low for this kind of logic to make any sense.
I think it's more realistic that in any sufficiently large company the bureaucracy is so unwieldy that sensible decisions become difficult to make and implement.
At the record level, I've seldom seen more than an add timestamp, and add user id, a last change timestamp, and a last change user id. Even then, it covers any change to the whole row, not every field. It's still relatively expensive.
reply