820 karma · joined July 2, 2012
openpgp4fpr:10B37026CB465449E31D0F41EBBC33985BFC0E17 aspe:keyoxide.org:V6KXI73HEWQGK4IOWU3E4KNYHI
[ my public key: https://keybase.io/yulian; my proof: https://keybase.io/yulian/sigs/oKGwmu8nNHyv00ecKTTXsrpCUOL3YmI44MAEY88Q-M4 ]
daegalus.at.hn
DR.dk has `ligetil` which is simplified/easy danish news. So if I can find similar, I use it. I can probably have LLM do easy for me. Also Noospeak for daily newsletter in Danish.
LLM has been great for language learning and translation.
I had already used and made my first prototype and realized my thumb cluster was not positioned right and not comfortable for use. So I have the PCBs for the Prototype 2 where the entire bottom row is shifted in. I learned a lot about PCB design and MCUs through this. Yours looks SOOO much better laid out compared to mine too.
Old pictures of prototype 1: https://photos.app.goo.gl/VhqQmjGyzTeBbKFQ9 ( have top and bottom plates, i just never used them because i found the thumb cluster issue quickly) (there is an ErgoDash pictured too that I used previously, modded to be wireless)
Life, becoming a father, moving to a different country, and so many things have put this project on hold, but I will finish it soon.
Location: Copenhagen, Denmark
Remote: Yes
Willing to Relocate: No
Technologies: Go, Rust, Dart, GCP, Azure, AWS, Kubernetes, Containers, DB, some Frontend/React/HTMX/Deno, Backend, Tools, Terraform
Resume: https://github.com/daegalus/resume/releases/tag/2025.03.04 (pdf, html/css, markdown)
Email: yulian@kuncheff.com
Languages: English, Bulgarian, Russian, Danish (in order of proficiency)
Website: https://yulian.kuncheff.com
My only caveat, is Denmark has very strict rules for contractors and employement, so you will need to have a legal entity in Denmark, or use a service like deel.com or similar that takes care of that stuff for you. It is just the way it is here, I don't qualify to be a contractor under Danish law.
I am part of a team building an automation tool for cloud provider creation of Projects/Accounts/Subscriptions (depending on provider). Our primary provider is GCP, and implementing that was fairly easy. Some gotchas, but easily surmountable.
Now we have gone multicloud to Azure and we need to add support (We were historically on AWS but moved 95% off, we still have some teams on there but we rarely build tools for it outside of Terraform modules). And the Azure API, MS Graph API and Go SDKs for bith are the biggest piles of trash I have ever worked with. Everything is a pointer, even string literals need to be made pointers, but sometimes they aren't....
Documentation is in accurate. Some apis take just the ID, others take a full path. Some of it is documented, many apis have the wrong one documented.
None of the APIs return related resources IDs, you have to search for all of it. So many name based searches. I had to add a caching layer for IDs during creation so I didn't have to lookup the same resource over and over (we use a state machine for creation and it can be resumed midway and other fun things, so we need a lot of checks and resume based code.
Overall it is the worst designed and implemented cloud provider. I would never recommend or choose it if given the power.
I ended up with a Meebook E-Reader P78 Pro. It is an android based e-reader with a stylus and note-taking capabilities. Even has the ability to enable Google Play Store.
I added Kindle, Library, and Audiobookshelf to mine, along with Obsidian and some note taking stuff. it works fairly well, nowhere near perfect, but its also much cheaper than the DC-1.
Maybe look into that also. There might be newer versions or alternatives. Maybe something from Boox
First to address the readme. Their goal for switch to GPL for closed devices is kind of pointless. For a closed device, they can still use it without modification. And even if they do modify it, how would you know. How would you prove it's your codebase they modified? The GPL does little to protect small projects. If they made money and got caught, they can just pay their way out of it. If they didn't make any money, well, no one would have probably found out until they they were a defunct company or the product was cancelled.
Second, more on the delusions of grandeur. Let's be real, this project is a small project with very little chance to grow big. It might become the defacto X server for old tech, but I doubt it would be used for anything new. And even if it is, not for many. The GPL won't protect it because it's obscure.
The GPL works for big high profile projects, like the Linux Kernel. It worked in the past because companies hadn't figured out a way around it, or that they can just ignore it and deal with the consequences later. They usually get away with it too, with little cost to them, as they have made their money.
I personally avoid releasing any of my projects as GPL. Because the likelihood of any of my projects being huge is minimal, and if they go big, I can change the license then. Maybe a non open source license like the Fair Source License that then transitions to MIT or Apache after 1-2 years.
I have never had a user complain about this. They just read the readme or the `help` and use it accordingly.
> oh lol… what % of go programs is used on windows? 1? 2?
I am sure it is quite a bit more than that, especially since I tend to see `exe` builds for most go tools I have used.
> You don't know how to do a thing that anyone writing a server process should know.
Oh I know it, I just don't think it is relevant for my day to day, or most of the go-made servers or tools I run.
Another thing that you seem to be assuming is that I am waiting for daemons to start. I used the term Containers instead of Docker specifically because the majority of them are in Kubernetes, or get converted to VMs for services like Fly.io. In those situations the daemon, or equivalent, is already running. I also use Podman, which doesn't have a daemon unless you need one.
And in the few cases where I would have needed to wait, I poll the docker unix socket for the /info path, and get the information that way.
> I have far more FOSS contributions than you do. Mostly in C/C++ or Python.
I never argued that, I have a paltry amount of FOSS contributions compared to most people interested in open source. I just said that if it matters so much to you that you are willing to label an entire dev community as inexperienced, and act all high and mighty about some standards that aren't seen as important these days, then you should teach us how to be better. Open that PR and show us the way. Obviously there is only 1 way to do things, and you are already well versed in it, guide us out of the dark hole we apparently live in.
> Maybe take the criticism instead of getting angry.
I am not in the least bit angry. I am discussing this, because I believe you are stuck in old ways and not adapting to the changes in the industry and development, especially in the areas where Go is used most, which is servers, devops, containers, and the like.
Also, I acknowledge there are industries, environments, etc that can't or won't use containers. But that is a small percentage of use-cases, and the engineers there are probably building things properly.
I will also never say no to implementing such a thing if I get an issue opened requesting it, a PR opened to add it for me, or the like. But I have not seen a need for it in years, both professionally or personally, to be added right away. And I feel like majority of Go devs have nothing against it, and would add it if requested. I know Miniflux for example, after their V2 rewrite into Go, added it 8 months later, due to a request. and have been maintaining/improving it since.
I had no clue how the sd_notify support was in Go in general, until this conversation with you. Not because I wasn't aware of sd_notify, I just never had to go looking for it or needed it. Took me 10 seconds to google it, find a library that saves me time, and I can add it to any server I need it in now. But I will do that if needed, not pre-emptively. Especially since 95% of the servers I make are for work, and dont need systemd. And personal stuff doesn't need it either. But if I opensource anything, and it is requested? I will add it without much fanfare.
I have yet to find a developer, go or otherwise, that cares strongly enough about getopt outside the hardcore FOSS groups that pays attention to this. I know of getopt, and I don't follow it, because no one ever told me to was the golden standard, I was under the impression it was one of many ways, not the only way, especially if you work with systems like Windows at any point, that doesn't follow it either. I also personally don't like the getopt style
> Yes, go developers have little experience. I see we agree.
Or you know, they have no need for it, and don't implement it. You are conflating inexperience, with not caring about the thing you care about.
> Them to tell systemd they started.
Why? Very few services care about your init system these days. Like I said, containers have made it so you don't need to worry about it. I have dealt with many supervisors and init systems, and I have 0 interest in specifically adding code to notify them. At best I will add a network endpoint, and it is up to the unit file to poll for it, if it can.
> As I said, most go developers have little experience. I see you agree once again.
No, I am arguing that in modern day server dev, it is an unnecessary skill to learn, so they don't either learn it, while having plenty of other experience, or they specifically don't care enough about it for it to matter to them.
> The old fork way is the portable way to do it with whatever init system (systemd included).
This assumes you care about an init system at all. Like I mentioned previously, the majority of places Go servers run on are either in Containers, or microvms. The init system does not matter. So few go devs take the time to implement support. It is not lack of experience, it is priorities.
I work in DevOps, ever since we moved primarily to containers, I have stopped caring about adding signal handlers, init system supports, etc. I write far fewer init files, be it unit files for systemd, or old school SysV stuff. It is an unnecessary set of features to add for projects that are internal, small, or run in containers. I am sure if a Go project gets big enough, it gets support for init systems, but those kind of projects are few, and init system support is an after-thought.
If you are so big on FOSS standards, maybe open a PR and add the necessary sd_notify features. Should be only a few lines of code if you import https://github.com/coreos/go-systemd/blob/main/daemon/sdnoti... and call it.
Most Go projects won't add this by default, because the use-case is infrequent for it for most places Go is used. Just like the article said a pro and con of the Go ecosystem is we don't need to worry about the rest of the dev world to gain the benefits of Go. So GNU/linux standards are not a priority. Especially with how easy it is to build cross-platform, using a Linux standard for all platforms is not perfect.
Maybe take the time to be open minded instead of calling the entire Go dev ecosystem "inexperienced", it is simply the case of priorities and needs to the community, and when there is no need for doing the things you mention, they aren't added, even if the devs know about them.
And I disagree that everyone should follow getopt, it is not the only way, and it is not necessarily the best way.
Signals and Backgrounding seem to be just developers that have little experience with that stuff. I can't remember the last time I did any sort of signal handling to do anything specific. And I haven't had issues with backgrounding, but that might be just the tools I use and the infrequency of backgrounding that I do.
Most servers I interact with or work on have some sort of `health` api endpoint to get that status because most servers in go are HTTP. What more are you expecting? I don't even know what you are referring to by the `old fork way` but I will agree most don't use sdnotify, as that makes the assumption you are running Go on something that handles systemd notifications.
I am fairly certain a majority of Go servers run in a container, specifically an Alpine, distroless, or scratch container. So communication would be over stdout or some kind of API endpoint, be it HTTP, GRPC, or any other TCP/UDP endpoint.
And I am a go developer that likes go and use it for 95% of my coding, including MMO servers. I love programming languages and have used and dabbled in many. I still go to go.
And many go tools I use tend to be pretty well written. But maybe this is just a sample size of 1 vs a sample size of 1 issue.
I agree that this looks like an accidental proxy of the API. Everything was so locked down back then, never thought I'd see the API exposed like this.
Back then the team was called Nucleus (hence in one of the responses in the article, the refType was NUCLEUS) who built and managed the backend api for Entitlements, Accounts, and Payments. It was a summer internship, so a year later when they offered me a position on the team, I stareted work there. By then the team was renamed EADP as it was slowly being merged with Origin (i forget what the DP meant, Data Platform?) hence one of the endpoints starts with `dp.`
Though, we did not have a GraphQL db back then, it was all Enterprise Java (OCI, Spring, Hibernate, etc) and some newer Groovy/SpringBoot stuff before I left. Running on datacenter servers (no cloud). But I worked on some fun things. I moved on from there after 2-3 years after some shit hit the fan, but I learned a lot of good backend dev back then from good engineers.
No clue what the team is like today, who the engineers are, or what is going on, but it is a shame to see something like this. We were very security conscious back then, and I even worked on a Bruteforce system to detect and handle bruteforce attempts on our login page. No clue if it is still active or running, but Security checks/reviews were part of our sprint task to reduce the chances and surface area of compromises.
But Cellmapper is not one I knew and it helped me a TON just now actually. Lots of great info and let me see all the bands currently in use, thanks for that.
Seems like a US phone will work mostly without issue in DK based on the 5G and 4G frequencies on Cellmapper.
Thanks again.
Denmark does not have trade-in deals. But between my wife and I, we can get a whole phone free with the trade-ins in the US.
We can also do international shipping and such through forwarding services, and that would eat into the savings, but still do so.
Then there is bands. THey are almost identical, except a few here and there, and I can't find a concrete place to get info on Denmark bands (multiple sources have different info or lack of info).
Is it worth switching out and going through the hassle and getting US pixels, and just deal with the Denmark prices, and try to sell the Pixel 6s we have. It is annoying.
I tried sending a message to support, and it threw an error, so trying here. I understand shit happens, I am not irate, but I would like to remedy this.
Anyways, even though dA of the past is gone, it was definitely an important part to many people, so thanks again.
But all these were talked about and considered before it was punted to a later time. https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...
But there is always TypeID in the meantime which uses UUIDv7 under the hood: https://github.com/jetify-com/typeid
Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: https://github.com/daegalus/snowflakes
Also Bazzite has an issue open to make `-dx` images.
It seems both are trying to do it all with a different main focus. Bazzite is Gaming but can do other stuff just as well. Bluefin is Dev but can do others.
I personally find Bazzite more diverse and capable.
In general Project Bluefin is newer, but seems to be trying to get into gaming too.
Likewise, Bazzite is considering developer images also. So I might switch to those.
But it's so easy to switch. I currently use Bazzite + Nix + HomeManager + Flatpaks and it has been fantastic. I only layer Tailscale and a few minor things that need be system level to operate right.
Bazzite/UBlue/Project Bluefin for Silverblue derivatives (it's what I use)
Ultramarine Linux or Nobara for non-Immutable.
At least you get friendly popups, and clicks to download from the software center. Worst case adding rpmfusion which is fairly easy these days but agree it's extra steps.