Hacker Newsnew | past | comments | ask | show | jobs | submit | kvemkon's commentslogin

> Writing Russuan is not that difficult

Never thought the difference mastering writing can be so significant. Just like to add what I understand regarding this. It's rather about not making any mistake writing by hand ca. 1-2 DIN A4 pages while someone reads a text (slow enough). I can't remember exactly but making only one (or two) mistake(s) and it is not anymore excellent (just good). Making 4-7 mistakes and it is not good (just sufficient). Making few more and it is bad which means failed. It's a long text with a very short path to fail.

Ukrainian is less difficult to write. There are claims that standardization/reform of Russian made it more artificial (far from natural people language) with overtaking too many words from Latin languages. When I read / listen to Belorussian I think they have even more luck with matching pronunciation/writing than Ukrainian. Which suggests this language is even closer to the common roots old language. (I'm not a linguist.)


Poles will hate me saying this, but I've always really struggled with their orthography, even though I am used to the Roman alphabet. I can see what is going on in Belarusian, Russian and Ukrainian, maybe even Czech to some extent. Polish is bizarre. Szcz is one letter in Cyrillic. I'm still baffled by l with the line through it.

"Grzegorz Brzęczyszczykiewicz. Chrząszczyrzewoszczyce, powiat Łękołody".

Whenever I, Czech, try to read such stuff, I feel a bit high. As in "what funny mushroom did I just eat"?

Hearing spoken Polish, on the other hand, is quite positively magical. But the orthography is, well, necromancy.


> "Grzegorz Brzęczyszczykiewicz. Chrząszczyrzewoszczyce, powiat Łękołody".

> Whenever I, Czech, try to read such stuff, I feel a bit high

well, duh, it's from a comedy film script. It's exaggerated for fun.


I know :)

SQLite 3.51.1

  $ wc -l ...
  265908 sqlite-amalgamation-3510100/sqlite3.c
Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.

The sqlite3.c file is generated from more finely-grained real sources, see https://www.sqlite.org/src/doc/trunk/README.md

SQLite is only deployed as a single file but the original sources are multiple files. They call it "The Amalgamation".

https://sqlite.org/src/doc/trunk/README.md


Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.

From my daily-use utilities, ripgrep and bat seem to have zero dependencies.

I believe ripgrep has only or mostly dependencies that the main author also controls. It's structured so that ripgrep depends on regex crates by the same author, for example.

Looking at Cargo.toml, ripgrep seems to have some dependencies and bat has a lot.

The tradeoff on one program can influence the other program needing perhaps the opposite decision of such tradeoff. Thus we need the arbiter in the kernel to be able to control what is more important for the whole system. So my guess.

> This increases the maximum core count per chiplet from 8 to 12. Furthermore, it increases the L3 cache per CCX/CCD from 32 MB to 48 MB.

I'd say the amount of L3 is not increased but adapted/scaled to the increased core count, since per each core there is still the same amount of cache available as before.

We get faster cores, so we need to get from 5600 to e.g. 6000 DDR5. Since core count is increased by 50%, we'd need 9000... DDR5^W, well yes, we'd need actually as planed before AM6 and DDR6!


There are already DDR5 CUDIMMs at and above 8000 MT/s, and 9600 MT/s has been demonstrated but none are currently in stock. By the time AMD ships Zen 6 desktop processors, the market should be ready with memory modules that will mean even the highest core count Zen 6 parts will be at worst only slightly more bandwidth-starved than their predecessors. And the lower core count Zen 6 CPUs with a single CCD should be able to provide substantially more bandwidth than their predecessors. All without requiring DDR6 yet.

Yeah, first of all we need to get 6 GHz with Zen 6.

> DDR6 will double the memory bandwidth over DDR5

Considering PC desktops. DDR4 is 3200 MT/s max JEDEC. DDR5 is available on AMD since 3 years and is 5600. DDR6 specification is almost finished. It looks like DDR5 will double performance just right before new DDR6 DIMMs appear. Thus I'd expect DDR6 to double the bandwidth just as late when the new memory standard arrives.


> DDR5 is available on AMD since 3 years and is 5600

Strange, I bought 64GB DDR5 6400MHz last year and apparently my motherboard can handle up to 7200MHz (or more with overclocking).


AMD's CPUs don't support more than 5600 MT/s without overclocking; they're still using the same IO die from Zen 4, so their memory controller is pretty outdated. Zen 6 should introduce a new IO die with a better memory controller, but for now 6000 MT/s is the fastest reasonable memory overclock for AMD desktops.

Intel's desktop CPUs from last year support up to 5600 MT/s with regular DDR5 DIMMs, or 6400 MT/s for CUDIMMs. Speeds higher than this are achievable, but are overclocking.

If your memory modules are rated for 6400 MT/s, they are most likely advertising the speed when using an Intel XMP or AMD EXPO profile to overclock the memory (and the CPU's memory controller). The JEDEC standard profile likely is no faster than 5600 MT/s. It's also possible that you bought last year a kit of CUDIMMs rated for 6400 MT/s without overclocking, brand new to the market at that time, and of no help whatsoever with any CPU that isn't an Intel Arrow Lake.


Now that you say that, I checked in bios and looks like you're right. I have 4 sticks of "DDR5-4800-16GB @6400MHz". It was probably marketing speed, but works stable and memtest didn't find any errors.

Though clarified at the start about Desktop, but missed JEDEC applying, of course, generally for the whole post.

> I could deal with some slower speeds due to cable length

Observing server mainboards reveals many PCIe 5.0 connectors for cables to attach PCIe-SSDs looking similar to SATA ones.


> buttons were clearly marked

Recently some UI ignored my action by clicking an entry in a list from drop down button. It turned out, this drop down button was additionally a normal button if you press it in the center. Awful.

> UI creation compared to MFC

Here I'd prefer Borland with (Pascal) Delphi / C++ Builder.

> relative resizable layout that's required today.

While it should be beneficial, the reality is awful. E.g. why is the URL input field on [1] so narrow? But if you shrinks the browser window width the text field becomes wide eventually! That's completely against expectations.

[1] https://web.archive.org/save


> Gnome

I can't imagine what I'd be doing without MATE (GNOME 2 fork ported to GTK+ 3).

Recently I've stumbled upon:

> I suspect that distro maintainers may feel we've lost too many team members so are going with an older known quantity. [1]

This sounds disturbing.

[1] https://github.com/mate-desktop/caja/issues/1863#issuecommen...


But how do you know, that if kroah.com would use Let's Encrypt it would belong to Greg K-H? What if his true WEB-site would be e.g. greg-k-h.com?


Right. Also, when it comes to the other aspects of TLS, such as preventing middlemen from making sense of what information flows between you and the server, what exactly is the threat in this case? I mean, it's a public blog post, which you only ask to read and so you are served.


It's not about threat, it's about privacy. I understand your statements but 'what is the threat in this case' to answer that: I don't want to know, I've moved on from those worries. Always encrypt.


What privacy? Whoever is watching your traffic can see you accessed their website with HTTPS, they can guess with high accuracy which article you are reading based on the response size.


Any hops along the paths and whatever they split off to by whoever. And of course they can, even with HTTPS the Client Hello is unencrypted.

Unencrypted data transmission just isn't a thing I'm interested in with it being 2025.


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

Search: