gsliepen

The SourceHut UI looks weird compared to commercial offerings, but every time I use it I am pleasantly surprised how fast it is and how little clutter there is.

I worked on an open source application, and some people wanted to use parts of it as a library in their commercial applications. So I started a consultancy due to that demand. I still had a regular job at the same time though, so there was never a need to gather enough clients to make a living out of the consultancy job.

Things I learned:

- Get an accountant ASAP, even if the income is small. Just the peace of mind that my taxes were being filed correctly was worth the cost.

- You don't need a perfect solution from the start, you are working with your client towards something they can use.

- You need to stay on top of things and communicate regularly, even if your client doesn't.

- Almost all clients wanted me to either come work for them or sell all (rights of) my work to them. This is understandable from their side, but if you want to stay independent you need to set some boundaries.

That's an easy answer, but multi-process mutexes are supported on Linux (and perhaps other OSes as well), and it would be nice if this could also be safely handled by something like Surelock. If it would, then it couldn't rely on VM addresses to order locks.

What about mutexes living in shared memory, and each process having a different address mapping?

Something similar: https://www.youtube.com/watch?v=7t7_naYJnHo Source code can be found here: https://github.com/spookysys/attiny-synth

A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinventing the wheel, and each of them has to deal with all the quirks of the graphics drivers. I think this is a big problem with the architecture of Wayland. There really should be a standard library that all desktops use. Wlroots aims to be one, but I don't see Gnome and KDE moving to it anytime soon.

I did move from physics to becoming a SWE. I could put the knowledge I gained doing 3D rendering and GPU compute used for visualization and simulations in my academic jobs on my CV, and get a job as a SWE that way. Later I moved to another job where I could use my physics background to help develop a new sensor.

As for how to market yourself: first you should convert your academic CV to one that is suited for the type of companies you are applying for. Unless you wrote something that ended up in Nature or some other super high profile journal, companies typically don't care about your publications. What they do care about is things like: can you communicate well? How well can you organize things on your own? Do you handle stress well? You did a PhD, so the answer to those things is yes, you just need to write that in your CV in a way a company recruiter/interviewer understands, even if they themselves are not from academia. So you don't have two halves that belong to different resumes, you are just one person and you just translate your resume to the "language" that your prospective job provider speaks.

Finally, your list of skills does not need to be a perfect match for what a company is looking for. Of course, there needs to be some overlap, but as long as it means you can pick up new things quickly, it will be fine. That and being a good fit for the company's culture are the most important things.

I did not start out with a unicorn role, but in I found ways to apply my physics background in my current job.

I used GIMP before I ever used Photoshop. My experience was the opposite. I think that means the UIs are different, but there is no one that is objectively better, it's just a matter of what your expectations are, which are set by whatever you learned first.

As for CMYK support: why do designers even need to use this? Sure, not every RGB is the same, and it took some while before we even got sRGB as some standard, but the same goes for CMYK: every printer has its own profile. I had the displeasure of trying to get the CMYK profile of a "professional" printing company that only accepted files in CMYK, and they didn't even know which profile their printers used. Ideally you would send a RGB file including the display profile your screen uses, and then the printing facility converts that to whatever CMYK they need.

Of course there are also special colors or effects outside of RGB/CMYK that you might want to use when printing something, that's something else.

You are assuming division itself is an O(1) operation. However, it also scales with the size of the number. So more correct would be to say that this naive method is O(sqrt(N) log(N) log(log(N))).

If you start with the problem of how to create a reliable stream of data on top of an unreliable datagram layer, then the solution that comes out will look virtually identical to TCP. It just is the right solution for the job.

The three drawbacks of the original TCP algorithm were the window size (the maximum value is just too small for today's speeds), poor handling of missing packets (addressed by extensions such as selective-ACK), and the fact that it only manages one stream at a time, and some applications want multiple streams that don't block each other. You could use multiple TCP connections, but that adds its own overhead, so SCTP and QUIC were designed to address those issues.

The congestion control algorithm is not part of the on-the-wire protocol, it's just some code on each side of the connection that decides when to (re)send packets to make the best use of the available bandwidth. Anything that implements a reliable stream on top of datagrams needs to implement such an algorithm. The original ones (Reno, Vegas, etc) were very simple but already did a good job, although back then network equipment didn't have large buffers. A lot of research is going into making better algorithms that handle large buffers, large roundtrip times, varying bandwidth needs and also being fair when multiple connections share the same bandwidth.

They shouldn't; the whole point is that the IP header is enough to route packets between endpoints, and only the endpoints should care about any higher layer protocols. But unfortunately some routers do, and if you have NAT then the NAT device needs to examine the TCP or UDP header to know how to forward those packets.

Could be an interesting chip for a future Raspberry Pi model? With Radeon having nice open source drivers, it would be easy to run a vanilla Linux OS on it. The TDP looks compatible as well.

Predicting the future is very hard (think butterfly effects, Lyapunov exponents and so on). It's also easy to extrapolate what would happen if the current situation continues unchanged, but very hard to predict what will happen in the near future in response to the current situation. People are already reacting to changes in politics and climate, thereby softening the blow, and maybe in some cases averting it.

I'm hoping Charles Stross knows this, and you should take his predictions as "this is what would happen if we did absolutely nothing about it".

Nice. Note though that you don't necessarily have to limit everyone else to email; some messaging platforms allow one user to post something using a webpage for example, and cause that to send email to another user, and vice versa. One data point: GitHub's issue tracker can forward issues as email, and you can reply to those back via email, and your response will end up as a new comment on the issue.

The problem of a Linux phone is not the hardware, it's the software. Are you doing to run a desktop OS on it? No. And if you want something like Android but not Android itself, how are you getting enough quality apps made? What about things like banking apps, who is going to port those?

While I would like a pure Linux phone, I think the only reasonable course of action is Android with something like Samsung's DeX on top. Maybe that is something they could do, but I don't see this happening any time soon.

I am not surprised, as most things that generate light are generating photons using quantum effects, and thus are true random. Furthermore, CCD and CMOS detectors themselves have a quantum efficiency less than 100%, meaning they only detect a fraction of the incoming photons at random. So, a regular light bulb in front of a webcam is already a quite high-bandwidth source of true random numbers.

So, there is nothing revolutionary going on there, this paper is more about how to build a system with micro-LEDs and a photodetector and how to remove any inherent biases in that system, with the obvious benefit of being able to make something very compact.

The Intel architecture is already Turing complete when you just use MOV instructions: https://github.com/xoreaxeaxeax/movfuscator. Of course, you don't even need instructions at all: https://news.ycombinator.com/item?id=5261598

I wrote a software synth myself with the intention of running it on Raspbery Pi 3 / Zero 2. Those are actually quite capable processers; sound synthesis requires very little RAM, both code and for maintaining state, so everything fits in the rather tiny cache. But at the same time, while these Pis use "little" cores, the maximum throughput of NEON instructions is actually the same as for the corresponding "big" cores like the Cortex-A72. With four cores, you can do in the order of ~10 GFLOPS 32-bit FMA instructions. With a sample rate of 96 kHz and 32-note polyphony, you theoretically have a few thousand FMA instructions per note to spend.

> My hunch is that many advocates would hesitate to put this in their project Readme, because they know that some companies might actually comply... by not using the code.

Definitely. And not only companies; even Debian rejected some packages because the upstream owners added restrictive "desires" on top of the actual licenses.

Well, they probably didn't have a choice in which GPU to use. You choose a SoC and then you are stuck with everything it comes with. What is most amazing is that they put in the effort to make a completely open source, upstreamed driver for its GPU.

I see only two possible paths for another GPU on RPis in the future: either Broadcom drops the VideoCore GPU and switches to Mali or Adreno (which I think is unlikely), or RPi stops using Broadcom SoCs and switches to something completely different. Still unlikely, but now that they have the RP1 chip taking over most of the I/O functions, it would not be too hard for them to change and still make boards that retain compatibility with existing hats.

Still, the RPi is made at a certain pricepoint, which very likely precludes putting in a flagship SoC, so even if they change, I'm not sure it will do wonders for GPU performance.

Something like MessagePack or CBOR, and if you want versioning, just have a version field at the start. You don't require a schema to pack/unpack, which I personally think is a good thing.

IMO, the GPU is actually a strength. It might not be the most powerful, but it is supported by the mainline kernel and libraries. Many other phone SoCs throw some binary drivers over the wall if you are lucky, and good luck if you ever want to upgrade the OS it came with.

Tinc unfortunately has a complete lack of maintainers with enough time to dedicate to it.

Tinc 1.1 should make setting up easier; it has a CLI to set up and add nodes without having to manually edit config files. And you can generate invitation URLs which can make it even easier.

And even in projects that are maintained by more than one person, it's usually just a single person responsible for most of the commits.

> But half of people earn less than the mean salary though.

That's incorrect. Half of people earn less than the median salary. Depending on where you live, it could be that a lot more than half earn less than the mean salary.

But... Debian is also a rolling release distro. Just use the "testing" or "unstable" suite. I am using Debian unstable on my main desktop since 1999, and had very little issues with it. The testing suite is the one which filters out most bugs found in unstable, and is something you can definitely use as a regular user.

At first glance it looks like this is very useful, but it only gives a speedup for very sparse graphs with an average degree of less than 3, unless your graph is very big, as in trillions of vertices.

I was thinking more about higher-order things, like a compiler being able to see that your for-loop is just counting the number of bits set in an integer, and replacing it with a popcount instruction, or being able to replace recursion with tail calls, or doing complex things at compile-time rather than run-time.

Why would that be impossible? Most programming languages are still Turing complete, so you can build whatever you want in them.

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations will be gone as well for practical purposes, and it would be interesting to see what programming languages could be made then.