marco_craveiro

That sounds extremely interesting, would be nice to have more details on this!

Pretty cool! One question though: if this was based on LSP in general, it could be generalised to any language, right? I wonder why they wired it to clangd specifically.

+1. And if you haven't read it, On Intelligence is also a great read.

Experience reports are also common as scientific papers. [1]

[1] https://sigdoc.acm.org/conference/2017/guidelines-experience...

I run Emacs on both Linux and Windows and I find that with more or less the same packages, the Windows Emacs tends to "slow down" after a while. I've used the profiler to track down a couple of things that were causing slowdowns (ibuffer auto refresh, etc), but still haven't quite go to the point where Windows runs as fast as Emacs. On both cases I have fairly long running Emacs sessions - around a month on Linux, when I pickup distro updates, and a week on Windows as we do mandatory reboots weekly. I recommend you try profiling to see if something shows up [1].

[1] https://200ok.ch/posts/2020-10-01_introduction_to_profiling_...

Magit brings an immense clarity to git workflows; I suspect I would not rely on staging as heavily as I do, if it weren't for Magit.

Completely agree.

I disagree slightly with the emphasis on "print debugging". I think what is missing is a body of theory around logging as a methodology. When I write code, I like to be able to look at the log file and "see" what the code is doing, when on DEBUG or higher. I think logging is a difficult but very important skill, and one which we are losing over time. If anyone is aware of any good books on logging (even if very old), do let me know. Seems like "logging theory" is a missing subject in Software Engineering.

I also don't see any contradiction between liking good logs and using the debugger when needed.

This. I was about to say,the kernel has solved this issue with patch series and tools like patchwork [1] and there is already a lot of experience on those workflows. What would be really nice is to have these kernel workflows in GitHub/GitLab (and, god forbid, stash/bitbucket), with UIs for mere mortals...

This approach is interesting but sounds more complicated than patch series, and therefore more error prone.

[1] https://patchwork.kernel.org/

Yes, I suspect the release notes are still being worked on. Or at least, I never noticed these sort of statements in the past.

Whats the difference between "oneTBB" and regular TBB, do you know? Cheers

I disagree, actually. I think we already have Windows and OSX for that, and even Android and Chromebooks. I think the biggest value of Linux Desktop is that it is an experimental playground for a melting pot of ideas.

I have used Linux on the desktop exclusively at home since ~1998 and, like Miguel, I went through a lot of pain. Heck, I remember the days when I couldn't even boot my machine without tampering with the kernel. And to compare that to what we now have, well its a world apart. I have been using Debian Testing for some 8 years or more and in that period I probably had one or two (at the very most) dist-upgrades that borked my system. And those have always been due to binary NVidia drivers.

For me, the importance of Linux is that it offers something that no one else can offer - I could take this exact same setup back to my home country and start teaching kids and they would have exactly the same setup as me, with top tools, even though their hardware would be extremely old. I do not think its important that Linux takes over the desktop, much as we all would love it. What is important is that it remains viable without changing its fundamental characteristics. And that, I think, has already been achieved.

I'm not entirely sure that is a fair comment, given his many FOSS contributions. I think Linux is a meeting point of many ideas, and Miguel (and Nat and many others) had their vision. Maybe they saw something like OSX. Others saw (and are seeing) something else. RMS had/has his vision. I think its perfectly fine to do your best to make your vision come to life and when that does not quite workout, do something else. Your contributions will remain, and can be used by others to build on. This is the true power of the FOSS philosophy, that it is the sum of disparate agendas, IMHO.

Piper looks amazing, shame its not on a package repo.

Wow this is great news! Does anyone know if they are considering variants with more RAM? Given how hungry Gnome/KDE and the web browsers are, 3 GB does not seem enough... I'd definitely shell out for more RAM.

Hi @fractionalhare, apologies for the spam but I am trying to read a post you made a few months ago on implementing Exp [1] but it seems the site is down. Is there a different source perhaps? Many thanks for your time.

[1] https://www.pseudorandom.com/implementing-exp

I can attest to that, I just bought Luigi Ballabio's book on QuantLib [1] and the quality is very decent.

[1] https://www.amazon.co.uk/Implementing-QuantLib-Quantitative-...

I think in Europe many people (including myself) do less than 69 miles per week. We rely a lot on public transport for commuting and use cars only for a few things during the week. I suspect the target market will be very large here.

Winner.

I'm surprised that Numenta [1] did not get a mention in the comments. As a mostly lay person (with moderate exposure to Computational Neuroscience) I quite like their approach even though it seems their results have slowed down a bit of late. I still haven't finished parsing BAMI [2], but seems very interesting.

[1] https://numenta.com/ [2] https://numenta.com/resources/biological-and-machine-intelli...

Wow great to see Pidgin still going. libpurple was a fantastic idea, and its great to see there is bitlbee integration [1]. Need to update my Emacs setup to use this! [2]

[1] https://wiki.bitlbee.org/HowtoPurple [2] https://200ok.ch/posts/2019-11-01_irc_and_emacs_all_the_thin...

Reminds me of the old FactoryFactoryFactory joke [1]

[1] https://gist.github.com/nkbt/4691b1ae3e78a6141aea

Its a shame you can't share the code, we could really do with a modern C++ implementation. Having said that, protozero looks very interesting [1], need to find some time to look into it.

[1] https://github.com/mapbox/protozero

Complete lay person here, so please bear with me if the question is very silly. Can this help the work on Perovskite solar cells [1] by any chance? I ask because it appears AlphaFold has applications in crystallography and (to the lay person) it seems that finding the right crystal structure is key in making a Perovskite solar cell that can last for decades.

[1] https://en.wikipedia.org/wiki/Perovskite_solar_cell

I'm sure someone will create a PostgreSQL extension for this... :-)

I second this request, I'd be very interested in any articles that talk about PostgreSQL integration with Kafka. Last I heard on this topic was debezium [1] but I quite liked the simplicity of Bottled Water [2].

[1] https://debezium.io/documentation/reference/connectors/postg... [2] https://github.com/confluentinc/bottledwater-pg

I've been postponing moving to Github actions, but I guess now I have no option!

Completely agree. I find that the right name takes ages to come about. Worse, it may require a lot of architectural refactoring that, many times, has nothing to do with the one entity you are trying to name. Instead, it is connected with the entire workflow you are designing. Nothing worse than spending ages coming up with the right name for a class, only to find out the entire class is not needed and you got the workflow all wrong :-) which I have done many a time, to be fair

Wrt crypto, this is the LBRY [1] approach I believe, and seems to work quite well.

[1] https://lbry.tv/

A bit of topic, but bear with me please :-) does anyone knowif EDB plans to (or already has) open sourced their Postgres Oracle compatibility layer?