HackerTrans
TopNewTrendsCommentsPastAskShowJobs

jlokier

6,116 karmajoined 8 年前
Mail: [email protected] LinkedIn: https://linkedin.com/in/jlokier

Knowledgable & helpful person, available for hire :-)

I'm looking for more work, ideally on a consulting / freelance / part-time basis.

LinkedIn is better than email to make first contact if you'd like to talk, whether for work or just chat about something you liked here on HN! (I often miss interesting one-off mails among the deluge, and don't check it every day.)

I work 80% time at a funded stealth startup as hands-on tech lead, with zero-knowledge (ZK) cryptography, Bluetooth low energy (BLE), and peer-to-peer distributed systems, linking physical devices as well as the usual web stack. Can't say more, but it is intended to become open source. This a really fun and challenging project, with a great team! (It's not on my LinkedIn - stealth).

With my remaining 20% I am currently available and looking for software dev and/or tech leadership and/or business strategy consulting.

I'm versatile but develop mostly low-level or "system" software in C, C++, Go, Rust and Nim, with Linux as my main OS (but MacOS and Windows also). I have about 30 years professional dev experience over a wide range of systems, from embedded to supercomputers, Linux kernel, database engines, as well as GUIs, the web, and even games. Good at performance optimisation, debugging. Also good math & physics.

I've worked as an Ethereum core dev (EVM), so I know that environment well, especially improving EVM database speed, which is a critical factor! Currently my rabbit holes are ZK cryptography speed optimisation, and a novel fast database engine (neither B-tree nor LSM-tree, but with characteristics of both).

(ZK = zero-knowlege cryptography).

comments

jlokier
·14 天前·discuss
> the possibility that Daniel and I are able to keep our personal opinions separate from the mission of our company

This isn't about opinions. Very large political financing is not a mere opinion. It has a much larger material effect.

I don't think it's possible to separate "mission of our company" from "large scale political financing", for purely structural reasons.

I think the legal and fiduciary concept of Conflict of Interest is relevant here, but perhaps only by analogy. https://en.wikipedia.org/wiki/Conflict_of_interest is quite informative.

In some business, political and legal roles, we deem certain structural relations to be a conflict of interest regardless of what people on those roles actually do..

The mere potential for excessive improper influence arising from the structure of their relationships and roles is what creates the deemed conflict.

As the owners of a company making substantial profit like Mullvad, you always had the potential capability to financially influence political outcomes on a scale which most your customers cannot, in ways that may seriously harm some of your customers and to be potentially against the stated mission of your company.

I think the relationship between running a company with an openly advertised public mission, or even an implied mission in the minds of customers, while in another role (wealthy private citizen) being able to make a substantial material action against the same mission, should be recognised as inherently a conflict of interest. But obviously it's one we can't avoid, as long as we allow people to get rich from a mission-driven company.

What we can do, is recognise that if someone actually takes a large material action against the company's mission, then they have gone a step further and demonstrated the conflict of interest.

We generally favour free speech, including political donations. But when the money for very large political financing comes mostly from customers who, by virtue of the advertising and marketing of the company's mission, are led to believe they are supporting the company's mission?

In my view, at that point the customers are being tricked into paying for something while their money is paying for something else which opposes the thing they thought they were funding.

At the least, it should be dealt with in a similar way that conflicts of interest are dealt with when, for example, directing multiple companies: By making sure everyone knows, so other people are able to consent or not on the major conflict issues those other people might have a view on. The analogy for customers is their consent shown by their informed decision to become or remain customers.

In Mullvad's situation, that would mean Mullvad should explain to customers, embedded clearly within it's public marketing of the company missions and values, that one of its current major owners receiving customer funds by way of profit, is the main financier of a political party which sponsors remigration in Sweden. Because that is clearly a thing some customers care about when evaluating whether to pay for Mullvad's services from now on. You know that, I know that, so there's no legitimate excuse for not letting customers who would care know.

Then, as you said, customers will be free to choose.
jlokier
·22 天前·discuss
Unfortunately SLAAC doesn't force upstream to provide a /64 universally.

Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.

Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.
jlokier
·24 天前·discuss
Any ideas why Nim seems missing from job and contract boards? Although it's niche, it doesn't seem that obscure compared with countless other niche things I see advertised.

I really enjoyed programming in Nim professionally, and got to know it well. But I've literally never seen a job ad which mentions Nim since then, except at the company I already left (Status), so that's not really an option.

After realising there's no work in it, I struggled to justify using Nim in new projects including personal projects, even though I like the language.

If anyone's reading this and looking to hire someone who knows (or rather, knew) Nim well enough to do quite advanced work in it and doesn't need training, please do drop me a line :-)
jlokier
·24 天前·discuss
It's a very scalable and almost fun task once you get into it.

Alternatives to VMware can run VMware VMs almost immediately, by translating the configuration and with only a few (or sometimes no) changes to the guest. Usually those changes are scriptable. I've done it a few times, moving between VMware and KVM of Windows guests pretty much just worked; the rest was optimisation, i.e. guest driver changes, etc.

Live migration is not realistic between different hypervisors, but a very short downtime per VM is realistic if the new hypervisor can adopt the old disk images directly, which some can. If you want, you can convert formats in the background while the VM is running on the new hypervisor. E.g. KVM and things built on KVM can do all these things.

So to each guest, it looks like a quick reboot with a quick hardware upgrade.

If that's coordinated properly, with a generic HA or Kubernetes setup, there's absolutely zero service downtime (if there are no serious mistakes), as it's just nodes within a cluster taken down one at a time while the others keep the services running, and state migrates among the nodes which are live.

Most of the things you'll change when migrating are the same for large numbers of VMs that are configured the same way except for their disk images, and easily minor things like MAC/IP. So after you've verified a small number, you can go right ahead and script the migrations for another thousand VMs, even doing them in parallel.

You don't need to migrate all VMs at the same time, and you shouldn't do that anyway. So the temporary hardware / cloud cost can be in the low single-digit percentage (for a few weeks to months at 40k VM scale, a few hours to days at 10 VM scale). You probably have some slack in there already, though, so might not need any additional hardware.
jlokier
·上個月·discuss
My point is the example code has a generic C bug, not depending on FAR, which is why it should be taught in good C courses.

Although the code worked on Win32, and works on most modern C compilers, it's not guaranteed to work on modern C compilers, especially with aggressive optimisation turned on.
jlokier
·上個月·discuss
Yes, there are a few exceptions to the Linux kernel's backward compatibility. I've encountered others, but I don't remember which any more. They are quite rare, though.

cgroups v1 might be the most irritating, because it was useful and something a shipped application or service might realistically use.
jlokier
·上個月·discuss
> Not if they're GPL licensed you can't.

Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.

You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.

The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.

The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.

If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)
jlokier
·上個月·discuss


  char FAR *p;
  char FAR *mem = farmalloc(65536);

  for (p = &mem[65535]; p >= &mem[0]; p--) {
    dostuff(p);
  }
Nice one.

To be fair to Windows, good C courses should still teach this, but I'm not sure if they do :-)

It's UB to set a pointer to before the first element of an array, or after the last element plus one. So, if it knows the call to farmalloc/malloc returns the start of an object, a modern C compiler on a modern architecture may, in principle, optimise the above to an infinite loop.

I've seen something similar on architectures (long ago) where a zero-bit-pattern pointer was a valid memory address you might actually access. Of course p-1 is not less than p when p is zero.
jlokier
·上個月·discuss
Thanks to the Linux kernel's extremely high backward compatibility, and virtually all the libraries being open source, you can ship old or frozen versions of libraries with your application if you have to. You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality, while using the distro version if that's more up to date and still has the functionality. You can do the same for auxiliary programs your application uses.

I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications.

There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies.

It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty.

You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date.

Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI.

One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.
jlokier
·上個月·discuss
> Did you hire a Linux release engineer

That's often a great idea!

But a full time hire? The GP's post implies that wouldn't make business sense for them, as even half a day occasionally on it is too much...

>> So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere. The number of tickets with Linux issues keeps growing and each one is taking more time to debug, all for a number of customers that is so small you can’t justify doing it.

Of course an experienced Linux release engineer can do it faster and more reliably. That's probably the cheaper option. But the business still has to decide their Linux customer or user base is large enough, or strategically worth supporting, to justify the cost however they do it.

For many businesses even fractional Linux support is not justifiable for the small number of Linux users and support requests they're unable to handle. Though I can't imagine that being the case for Anthropic!

(Hint: This is one of the things I consult on, if anyone is looking to pay for quality Linux release engineering and platform testing. I have hundreds of historical and current Linux VMs, multiple architectures old and new (esp. x86, ARM and RISC-V), some of them embedded, fairly deep knowledge of how the kernel and libraries work together, and test harnesses. Also I test some compiled applications for portability across other OSes and architectures, including Windows, MS-DOS, MacOS, BSDs, SunOS, HP-UX, etc. going all the way back to the early Unix lineage.)
jlokier
·2 個月前·discuss
Demand for DDR3 is up because people who want DDR5 or DDR4 but can't afford either any more are choosing DDR3 and old DDR3-compatible systems to put it in, instead of what they really want.
jlokier
·2 個月前·discuss
I think they mean that Apple is shipping the M5 now, while Asahi only runs reasonably on the M1 (from 2020!), half-works on the M2, and won't run at all on the M3 and above.

Asahi developers have done amazing reverse engineering and driver development. But for the foreseeable short-term, there's no chance of it being installed on a current M-series iPad; it can't even be installed on a current Apple laptop.

I think the Macbook Neo might change that. It's not even an M-series, so there's a quite a lot of work to get Linux running on it. But because it's so much cheaper than the other laptops, and quite powerful, it makes a good "spare" laptop for people who can afford an M-series. And it probably has many internal functions similar to the M-series. I think it might get more attention by reverse engineering enthusiasts over the next couple of years.

Also, AI agents can help experts with reverse engineering labour in ways they couldn't a year ago. (I'd love to do this, if anyone out there wants to pay for it :-)
jlokier
·2 個月前·discuss
A byte is not always 8 bits on old machines, though it is standardised as 8 bits nowadays.

This is why network RFCs talk of "octets", to avoid the ambiguity. Octets are always 8 bits.

https://en.wikipedia.org/wiki/Octet_(computing)
jlokier
·2 個月前·discuss
Linux did /dev/random first, so naturally it had the oldest design for a few years, without the security expert scrutiny and experience, which the other OSes had for their implementations.

OpenBSD didn't exist yet when /dev/random and /dev/urandom were created for Linux.
jlokier
·2 個月前·discuss
Back when I did much work outside, I used a laptop that had accidental transflective characteristics. In bright sunlight, the LCD actually become quite clear monochrome, with some pixels acting as mirrors and others not, but I don't think they designed the LCD to do that.
jlokier
·2 個月前·discuss
It's one of the nicest things to do if you love computers, and great for your health compared with staying indoors.

> Could one actually work like this, typing and everything? After my “heart-rate discovery” I decided I had to try it. I thought I’d have to build something myself, but actually one can just buy “walking desks”, and so I did. And after minor modifications, I discovered that I could walk and type perfectly well with it, even for a couple of hours. I was embarrassed I hadn’t figured out such a simple solution 20 years ago. But starting last fall—whenever the weather’s been good—I’ve tried to spend a couple of hours of each day walking outside like this

https://writings.stephenwolfram.com/2019/02/seeking-the-prod...

https://quantifiedself.com/blog/stephen-wolfram-finds-workin...
jlokier
·2 個月前·discuss
They use TOTP for 2FA (industry standard), which doesn't require a phone.

Their help page lists a bunch of 2FA app options, all of which run on phones, so it's understandable to think a phone is required. (I'm disappointed they don't list the app I use, which is Aegis Authenticator.)

But actually you can use any TOTP app, and they don't all need a phone. For example, macOS (desktop) has built-in TOTP 2FA as part of the password manager.
jlokier
·2 個月前·discuss
The GPL has no effect on this issue. For service providers like AWS, who provide the service not the software, the GPL doesn't require them to do anything differently than with more permissive licenses.
jlokier
·2 個月前·discuss
People are rightly concerned that AI chatbots could result in worse customer experience, so I'd like to share my anecdote.

I recently had the best customer support experience I've ever had, and it was an AI chatbot, helping my in ways I would not expect from a first-line support human.

Recently I opened the chatbot window on the site of a supplier of electric vehicle chargers, and asked some obscure things about how I could access and modify the charger in a non-standard way. I explained I was doing some R&D testing of a novel way of using the chargers, and I would need to temporarily reconfigure the public unit we had already installed in an unusual, non-standard way, rewiring its network to intercept traffic via transparent proxy, make it behave a little differently than it normally does, and that I didn't have the credentials.

I was expecting the first-line person or bot on the chat to be unable to handle my non-standard request. What I was hoping for was this would start the process of getting me to someone who could help. I expected to take a few days or weeks to reach someone appropriate in the company, perhaps a sympathetic technician who could understand what I was trying to do.

To my amazement, in the first response it one-shotted a nearly complete answer to every part of my question, including the detailed and implied parts I'd left out for a later interaction. It figured out what I was doing and what that needed, told me exactly what to do and why, and showed me that it understood every aspect of my request. There were things in this I doubt anyone ever asked about before.

Because the answer so complete I didn't really need more. I asked it some things, e.g. about electrical safety, just to confirm my understanding of the one-shotted answer. In every reply, the chatbot was insightful, informative, helpful and correct, and I didn't need to explain things twice, or wait on hold, or be transferred to anyone else.

I don't know what service they were using, but whoever implemented it, hats off to them for using good technology and providing it with high quality data about the products they are supporting.

Honestly, if AI customer support calls or chats can be made that good consistently, that sounds great.

(That was a stark contrast to my awful expereinces with support at banks, where many humans made mistake after mistake, contradicted each other, and seemed to struggle to understand simple things. Particularly the one where a bank required me to fill out a form with basic company info, then it took 14 hours of phone calls and hold time until I got to the one person who understood straight away that the entries on the form were correct, had to be that way, and they could tick the "it's done" box. My execellent AI bot experience suggests a good one will always understand things like that on the first iteration, as if they are the best-trained and best-informed humans available. But other, worse AI bot experiences suggests the 14 hour calls would become infinitely long, never able to resolve the problem, leading to things like unnecessary account closures and locked funds needing a court to resolve.)
jlokier
·2 個月前·discuss
That should work, but you need an Ollama Cloud account and for much usage you need to pay the Ollama Cloud $20/mo or $100/mo subscription fee.

Using the API from DeepSeek or OpenRouter also requires a fee, but it's a different, pay-as-you-go payment model.