The reason tables for layout were so bad was that the table as a whole couldn't be rendered (laid out) properly until every cell was fully rendered first, including images with unspecified width/height attributes as well as dynamic cell dimensions based on free-flowing text, etc. Floating div tags still cause redraws for containers with content requiring dimensions to be determined at runtime, but at least something would display. It was also easier to see which divs were causing redraws because their dimensions were not fixed, and thus developers could focus on those specific regions to try and add fixed dimensions.
edit: My comment sounds a bit angry, but it's not directed at you personally, so keep it in mind ;)
> The reason tables for layout were so bad was that the table as a whole couldn't be rendered (laid out) properly until every cell was fully rendered first, including images with unspecified width/height attributes as well as dynamic cell dimensions based on free-flowing text, etc [...]
That was purely a limitation of the CSS rendering engines, it had absolutely nothing do to with table layout themselves, from a developer perspective. There is no reason this problem cannot/couldn't be worked out by CSS rendering engine developers. I get what you are saying, but it wasn't a good enough reason to dismiss tables entirely (and that wasn't the biggest reason used back then when "a list apart" writers decided that tables were cancer).
Floats were so good yet developers had to resort to CSS frameworks and grid frameworks for years in order to make working with CSS bearable? No, float positioning was horrible, un-intuitive and just a hack. Again, the culprit was CSS itself (and by extension the rendering engines), not the developer using tables.
The irony is that all these CSS frameworks were essentially tables re-implemented on top of "floating divs".
A good measure of whether a web spec is good or not, or pragmatic enough or not is how much effort developers go through in order not to use that spec directly. Generally, if using a framework on top of the spec to make that spec somehow useful is what most developers do, it means that the spec needs to be revised and improved in order to fulfil the needs of the developer, not the other way around. Obviously that doesn't apply to low level protocols like WebRTC and co, but CSS isn't a low level protocol, it was supposed to make web presentation easy, and it failed at it for decades. That's all I'm saying.
Just thank god we now have at the very least Flexbox and Grid. Which makes bootstrap and co completely redundant even for devs allergic to design.
I'm very thankful for Varenecline (aka Chantix/Champix); it's what got me to quit after many years of pack-a-day. I didn't even set a quit date when I started. That drug took away every tiny ounce of satisfaction I ever got from smoking. Every cigarette became a cigarette that did not give me what a cigarette is expected to provide. The best way I can describe what happened to me is that I felt like a non-smoker trying to smoke, and all I got was the scent and flavour of licking an ashtray with none of the brain-altering effects.
It's been over a year now, and I can't imagine going back. The only trigger I have is seeing someone else smoke, and even then it has never been more than a fleeting thought that dissipates within seconds. I know exactly what 2-3 puffs would do to me, and I have no interest in going back. I've never had the urge to buy a pack myself or to bum off someone. Smoking is now well into my past, and for that I am thankful.
I got the well-known "nightmares" from Verenecline, but I actually really enjoyed them. Those dreams were some of the most vivid and intense I've ever had the joy to experience. In fact, I still have the last 50 1mg pills leftover that I didn't need to use, and I've only kept them because I know I'll eventually use them just to revisit that kind of dream state. :)
For those in Europe, a similar medication is sold under the Tabex brand name. The active ingredient seems to be different (cytisine) but the effect is the same: no satisfaction from cigarettes, just the bad smell/taste plus some mild stimulation (at least I felt less sleepy in the first few days quitting with Tabex as opposed to cold turkey). I liked to visualize the effect of this drug as: binding to the same receptors in my brain as nicotine, robbing the dangerous molecule of it's power.
It still takes a tremendous amount of willpower to stay off the various forms of nicotine after the initial quitting. The pretense of having that first nicotine hit, seeking a consolation from life events, an excuse to make yourself feel better and all the other lies you'd be telling yourself are still very tempting (and exactly the reason I have been using the same pack of medication to __quit__ several times already.
Agreed, I don't understand why anyone reaches for uuid v4; it's the dumbest thing out there that sees regular use for no reason whatsoever. The number of developers who reach for uuid v4 is scary; I swear they don't understand what it contains, or care to think critically about their use case. The worst is reading about using uuid v4 for "offline client-side ID generation", such that any client can fixate object IDs that wind up in the server's database, and in fact are likely NOT unique if you have nefarious clients purposely generating duplicates client-side.
There is also no reason to give up 6 reserved bits of a uuid v4's 128 bits (it's only 122 random bits + 6 bits of unnecessary version info). If you want random IDs, make your own. Simply generate 16 bytes of raw data; or combine two random 64-bit integers; or combine a timestamp prefix with random bytes at the end. Your needs probably don't warrant exactly 128 (well, 122 bits) that uuid v4 gives anyway, so you can customize to a specific number of bits. You can also use base62 (0-9, A-Z, a-z) or base64 instead of hexadecimal (0-9, A-F) to reduce the number of displayed characters (eg. in URLs), while omitting the stupid hyphens of a uuid too.
tldr; uuid v4 shouldn't even exist, and certainly should not be used unless integrating with pre-existing systems.
I'm the OP. Well, I've used UUID to generate ids on the client-side for a metrics system. Well, if someone submitted duplicated data, my server would ignore it. The context is critical to decide whether you can let clients generate an ID or not. In my case, the worst that could happen would be a Denial-of-Service attack if someone found a weakness in the UUID algorithm I relied upon.
And this right here is why PostgreSQL will never overtake MySQL and its forks. The entire industry is sick of these excuses regarding process-per-client instead of a proper multi-threaded model. There may have been a valid argument for this 15 years ago, but not anymore.
Your definition of "reasonable number of long-lived connections" is anything but reasonable. Then "connection pools address a lot of the other cases", when a connection pool/bouncer is unwanted, unwarranted, and just adds another point of failure that needs to be deployed and maintained.
Firstly, it's not the goal of the PostgreSQL project to overtake MySQL or other databases, but to serve the existing/new users. This also means we're investing the development effort in a the highest benefit / effort ratio. Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort ratio is so utterly awful no one is going to do it. There are always better ways to invest the time / effort. Especially when there are practical solution / workarounds like connection pools.
Secondly, every architecture has pros/cons, and switching from processes to threads might help in this respect but there are other consequences where the process model is superior (some of which were already mentioned). Focusing on just this particular bit while ignoring the other trade-offs is rather misleading.
And no, the arguments did not really disappear. To some extent this is about the programming model (locking etc.), and that did not really change over time. Also, PostgreSQL supports platforms, some of which may not have particularly great threading support.
I'm not claiming there are no workloads / systems that actually need that many long-lived connections without a connection pool. In my experience it's usually "We don't want to change the app, you have to change the DB!" but fine - then maybe PostgreSQL is not the right match for that application.
> Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort ratio is so utterly awful no one is going to do it.
Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are gaining marketshare over Apache httpd.
I love PostgreSQL and don't want to see it becoming the next Apache httpd, slowly but surely fading. Perhaps FAANGs could fund such refactor.
Perhaps a cheaper solution was to incorporate pgBouncer inside PostgreSQL so it would naturally sit in front of PostreSQL in the default installation without extra configuration.
> Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are gaining marketshare over Apache httpd.
Maybe, we'll see.
It however assumes the other (thread-based) architecture is somewhat universally better, and I doubt that's how it works. It might help the workloads actually requiring many connections to some extent, but it's also likely to hurt other workloads for which the current architecture works just fine.
But let's assume we decide to do that - such change would be a massive shift in programming paradigm (both internally and for extensions developed by 3rd parties) and would probably require multiple years. That's a huge investment of time/effort, with a lot of complexity, risks and very limited benefits until it's done. I'd bet there'll always be a feature with better cost/benefit ratio.
So reworking the other architecture might actually gain us some users but loose others, and drain insane amount of development resources.
> Perhaps a cheaper solution was to incorporate pgBouncer inside PostgreSQL so it would naturally sit in front of PostreSQL in the default installation without extra configuration.
Yes, I already mentioned that's quite likely to happen. There has already been a patch / project to do exactly that, but it didn't make it into PG14.
I feel sorry for average non-technical people who get hoodwinked into VPNs. The majority of people have absolutely no need for a VPN for "privacy" reasons, particularly these days with wide adoption of TLS which prevents ISPs from reading and/or injecting content into streams.
Modern cases for a VPN:
1. The few countries/regions with severely corrupt governments/ISPs.
2. Accessing region-locked services; eg. another country's Netflix.
I use the TunnelBear VPN because it has a 500MB/mo free limit and I use their different servers in different regions to check the localization of prices/text on my sites.
And if ad blockers didn't exist, they would still increase the number of ads anyway. If nobody could block ads, there would be no incentive for companies to be scared about having "too many ads", as there would be nowhere for users to turn to (ie. ad blockers).
aka the "you actually want to show ads to paying customers, because you've got evidence they have disposable income and a willingess to part with it" phenomenon.
The password/key never hits the Bitwarden servers. Bitwarden servers are just storage buckets for encrypted payloads. The server is never involved in the encryption or decryption process; this is the case for Vault, and now Send. All encryption and decryption is handled exclusively by clients.
Note the URLs used; all the important bits are contained in the fragment (after the "#"). HTTP clients do NOT send the fragment to the server; a "#" and everything after it is stripped before being sent to the server. Bitwarden's Send URLs contain an identifier as well as the decryption key in the fragment. When you load the page, JavaScript is able to read the fragment; an async request is made to fetch the encrypted payload using the first half of the fragment (ie. the payload's unique ID). Then the client–in this case JavaScript–decrypts the contents using the second part of the fragment as the key.
What an awful decision made by the developer. It is entirely unnecessary to display any account-related info to recipient(s). Some of us use a unique email address per company/site/account, and I find it unacceptable that my account's login would be exposed like this. It's the first piece of information required to begin brute-forcing or social engineering access to the account. I also use two-factor, but that's beside the point.
A: "Soldat" or "Soldaat" means "soldier" in the following languages: german, dutch, norwegian, swedish, danish, french, slovenian, afrikaans, russian, catalan and romanian.
Still no support for monthly, quarterly, or yearly aggregations. This is useless software at every company I've worked at; every business person wants statistics grouped into monthly, quarterly, and/or yearly buckets. "Last 30 days" is useless; I need each month in its own bucket (eg. January being 2021-01-01 00:00:00 to 2020-01-31 23:59:59).
