Hacker News new | past | comments | ask | show | jobs | submit | naranha's comments login

Stuff becomes legacy not because of the language, but because of outdated libraries or frameworks or unavailable/uninterested developers. For me PHP is legacy, because I refused to work on PHP codebases, except I find someone who's willing to do the job for me.

At least couchdb is also append only with vacuum. So it's maybe not completely outdated.


High performance has never been a reason to use couchdb.


I build an internal project using CouchDB2 as a backend in 2017 and it's still used today. CouchDB definitely surpassed my expectations in what has been possible to do with it. Its biggest advantages are that data sync is effortless and that it uses HTTP as a protocol, so you can communicate directly with it from a web application.


uuidv7 will be supported in PostgreSQL 17, at which point generation should be as fast as uuidv4, or if you implement it in pgsql now it will be as fast as the proposed ULID algorithm.

Insert performance could be even better, iirc for BTree Indexes monotonic increasing values are better than random ones, but feel free to correct me on that ;)


Commenting on this a bit late, but in case anyone reads this later too:

UUIDv7 support unfortunately didn't make it to Postgres 17, since the RFC wasn't completely finalized yet by the time of feature freeze (April 8), see discussion on pgsql-hackers:

https://www.postgresql.org/message-id/flat/ZhzFQxU0t0xk9mA_%...

So I guess we'll unfortunately have to rely on extensions or client-side generation for the time being, until Postgres 18.


In that case I don't understand why the author didn't go for uuidv7? It seems like existing tooling (both in database and outside) deals with it better, it seems like there are no downsides unless you expect your identifiers to be generated past 4147 but don't care if they are generated past 10889 (I'd love to hear that use-case, seems like it must be interesting).


As with databases it always depends, for maximum insert performance you'd actually often go with random uuids so you dont get a hot page.


Hot page?

Using a monotonically increasing PK would cause pages in the index to be allocated and filled sequentially, increasing throughput.

Using random UUIDs would lead to page-splitting and partially-filled pages everywhere, negatively impacting performance and size-on-disk.


Not always, this article describes the problem: https://learn.microsoft.com/en-us/troubleshoot/sql/database-...


Exactly, with one big insert its better to have a sequential value, for many small ones its often better to not.

As with all databases, measure before you cut.


The way to take advantage of the bandwidth of multiple storage devices is to distribute concurrent writes across them, rather than forcing everything to commit sequentially using contended locks or rollbacks.


The DB (or any application) should not have any need to know what devices are underneath its mount point. If you’re striping across disks, that’s a device (or filesystem, for ZFS) level implementation.


idk, when I want productivity I go with nodejs these days. lodash for some quick data crunching and pg or mariadb for db access using promises simply beats native php functions. with express you can spawn a http server in under 10 lines, while with php you need to setup apache/nginx or docker.

at some point in the past PHP was the most productive tool for some quick & dirty coding, but not anymore for me.


I recommend checking out FrankenPHP, where you can spin up a production php server with a single cli command, or compile your php into a self-executable binary.

I’m a contributor over there.


In the graphics benchmarks it performs mostly worse than the 5600g/5700g. That's pretty disappointing 3 years later.


It's the lowest end of the consumer APUs. The 8600g and the 8700g are those models replacements.


The 5600G had 7 graphics compute units, the 8500G only has 4; if it performs within 10% of the 5600G, the compute units are almost 60% faster than 3 years ago.


They had better be; 5000G chips are based on old GCN Vega stuff, while these are based on the latest RDNA3 architecture. They're also clocked MUCH higher, as AMD focused a lot on clock speeds when developing RDNA2.

In fact, pretty much all of the performance gain going from a 5700 XT to a 6700 XT is based on the latter's higher clock speed, as their specs are very similar otherwise (although a 6700 XT has 12 GB 192bit memory and a heap of cache, whereas the 5700 XT has 8GB 256bit memory that runs a small bit slower, and crucially, way less cache).


Yeah it's a shame, you really have to step up to the 8700G (or at least the 8600G) to get the true APU experience with modern graphics performance. That said even the bottom of the range significantly outperforms Intel's integrated solutions, and I support anything that gives them a kick in the pants to ship better iGPUs - one step closer to my work laptop being able to run the Windows desktop at 4k without turning into a laggy mess.


At least you hope, it is more power efficient due to advanced manufacturing process. And then a totally disappointment: new CPU consumes significantly more both under load and idle. The AI-extensions are also missing. ECC is missing in all 8300G/8500G/8600G/8700G.


Got a link for the ECC claim? Last I read, the ECC issues with the AM5 platform were mostly fixed (at least many vendors are claiming ECC compatibility again, which they didn't a year ago).


I've just searched for official ECC support on * 8700G https://www.amd.com/en/product/14066 * 8600G https://www.amd.com/en/product/14071 * 8500G https://www.amd.com/en/product/14086 * 8300G https://www.amd.com/en/product/14091

5xxxG are also known for missing official support, only PRO favors have it.

Since ECC is for robustness I'd really prefer when both AMD and ASUS/ASRock/Gigabyte/MSI/... mention ECC support in the specification. Last time I've checked, only ASUS did mention it for consumer AM5 mainboards. (Gigabyte did it for (at least) one simple but expensive server mainboard.) While for AM4 it wasn't such an issue for other manufacturers too.


Historically, only the PRO variants of AMD's APUs have supported ECC.


If comparing to 5600g/5700g, there's no difference in AI extensions or ECC. AI is new for 8600g/8700g, and ECC is only in "pro" APUs.



Does this stay compatible with the old uuid column type, as uuidv7() uses the same 128 bit format as gen_random_uuid()?

That would mean it's easy to update old apps, as we would only have to change the default value for the columns.


Yes, internally it's the same as every other UUID (16 bytes, passed by reference). There's no reason to store / represent it differently.


Yes, we have already updated our in-app UUID generation to use v7 UUIDs and are storing them in regular postgres UUID columns (postgres 14). Works great!


Note that, as jmull says in https://news.ycombinator.com/item?id=39262286 , embedding timestamps in every uuid can potentially expose private information.


Yes, you can check UUIDs to see if they’re v7, and extract the timestamp if so. This seems to me less problematic in most cases than being able to guess the next ID (as is the case with numeric IDs). At least for us, anybody with access to the ID also has access to the time the record was created, so there’s no new information being exposed.

It’s a good thing to keep in mind though for sure.


Yes, you can use v7 today with uuid columns, you just need to add a custom function (or the more performant pg_uuidv7 extension) to generate them.


Remote desktop is not quite there yet it feels. It's the only reason to still use X imho.


This should be the replacement for most of the legacy X-based (like for example Toger VNC) remote desktop tools:

https://gitlab.gnome.org/GNOME/gnome-remote-desktop https://www.mankier.com/1/grdctl

This is already available in Fedora in some capacity. Main focus seems to be on RDP, with some support for VNC as well.


How well does 'X forwarding' ("Wayland forward"?) work?

A lot of time I don't want a remote "desktop", but rather just launch an app and have it sent over an SSH tunnel (-X/-Y).



Awesome, this might be just what I needed! I need to run vscode and it seems to be possible if you launch it with --enable-features=UseOzonePlatform --ozone-platform=wayland . I'll play around with it the next days, thanks!


Thanks for this, almost forgot it. Works great on Fedora Workstation 39.

Wayland forwarding over SSH: done


RDP as a protocol does support remoting just apps (RAIL: Remote Application Integrated Locally, or RemoteApps).

However, for Wayland compositors, this is a distant future; right now, Mutter supports connecting to existing, already running session (desktop). Ability create a new session over RDP is in the works. Everything else is after that.


Last time I tried to use Wayland on my NVidia laptop it didn't work well, both with the proprietary driver and with Noveau. I can't remember the details and I have too many open apps to logout and try again now. I switched back to Xorg and forgot about it. It was January this year, Debian 11.


>NVidia laptop didn't work well on linux

closing as WONTFIX, everything working as expected


I know, but it works well with X11.


Software in Debian 11 is now 2 years old as far as features and bugfixes are concerned.


I had weird flickering and micro screen freezes with my 2070 on Arch using Wayland on my new desktop build 3 weeks ago. Switching to Xorg fixed everything.


Xwayland will still be there so there will be way to remote desktop to xwayland.


freerdp has some integration with Gnome and KDE, but yeah, it's work in progress still.


I'd take the French highway over the Autobahn any day. Yes it costs money, but people are driving in a much more civilized manner and they are well maintained.


I'm sorry but you certainly never had to cross France from one side to the other in recent years.

My favorite highways are the Spanish ones. You can drive for hours completely calm without a worry in the world. Very long straight roads with calm people driving. It is a complete breeze to drive for hundreds of kilometers without stressing you. The only problem is when driving close to urban centres over there.

If you look on statistical data, you will see that France keeps increasing the death on the roads since the past ten years, whereas Germany keeps lowering: https://etsc.eu/euroadsafetydata/


Thanks for the statistics, that's interesting. It can also be misleading, from what I could find, less than 10% of traffic deaths occur on motorways vs. rural/city roads and motorway deaths have actually been decreasing in France steadily since 1990 (this is only from a quick Google search).

Edit: According to the OECD itf (random source I found on the internet ;)) Germany had 317 deaths on motorways vs 201 in France in 2022.

https://www.itf-oecd.org/sites/default/files/germany-road-sa... https://www.itf-oecd.org/sites/default/files/france-road-saf...


I did similar trips through Germany when I was just old enough to drive. One time I was driving 200 in the left lane and a truck changed lanes just in front of me, because the driver didn't expect me to drive this fast.

I had to do an emergency break maneuver and almost crashed into the truck. Only then it dawned on me that driving this much faster than the other vehicles is very dangerous. To me it is completely nuts that this is allowed. If you want to drive fast, you can always drive on race tracks...

I rarely went over 130kmh since then, nowadays I mostly cruise at 100-110kmh, because it is the ecological sweet spot of my car and in general it's less stressful.


The Germans are aware, but there are tons of people on the road from other countries that forget sometimes.

And we may feel fancy at 200KM/h but you really have to watch out for the anry BMWs/Audi/Merc and so on that will want to pass you at 250-300KM/h.


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

Search: