canpolat

@canpolat@programming.dev
66 Post – 75 Comments
Joined 1 years ago

xkcd git commit

Here is the link to the original website (an NGO that monitors blocked websites in Turkey): https://ifade.org.tr/engelliweb/distrowatch-erisime-engelledi/

And here is the Google translation of the text on that page:

The IP address of the DistroWatch platform, which provides news, reviews, rankings and general information about Linux distributions, was blocked by the National Cyber ​​Incident Response Center (USOM) on the grounds of "IP hosting/spreading malware".

I wouldn't expect it to impact Fedora, but this will probably be significant for Rocky/Alma.

3 more...

I no longer look forward to updates.
[...]
It seems to me that some software is actually getting worse, and that this is a more recent trend.
[...]
Why does this happen? I don't know, but my own bias suggests that it's because there's less focus on regression testing. Many of the problems I see look like regression bugs to me. A good engineering team could have caught them with automated regression tests, but these days, it seems as though many teams rely on releasing often and then letting users do the testing.

The problem with that approach, however, is that if you don't have good automated tests, fixing one regression may resurrect another.

Every time I see a new update, I think: "I wonder what will break after this update" and postpone them as much as I can. Software updates shouldn't cause anxiety. But they do these days...

Who is this particular developer

As far as I understand from the discussions about the topic, Maxim Dounin was one of the few core developers of nginx. Looks like Wikipedia has already been updated.

I don't follow it very closely, but as far as I know, they are the only one implementing the open protocol they designed (which doesn't interoperate with ActivityPub). However, there seems to be some efforts for creating a bridge: https://www.docs.bsky.app/blog/feature-bridgyfed

As you said, there are some recognizable faces and that may impact the adoption. But not being compatible with ActivityPub is a real bummer.

I think you have a better chance if your instance focuses on a topic instead of being general purpose. That's the reason I chose programming.dev. All communities there are related to programming so when I sort by "local" I see something interesting even though I haven't subscribed to that community. And that increases my interaction with those communities.

Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.

Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.

2 more...

I don't work much with Linux systems these days, but I would vote for $ sudo over #. Two reasons:

  1. It's easy to overlook the prompt. That part is basically "some characters before the actual command", so I don't normally pay attention to it.
  2. # is also used for comments. I think it would be confusing to use the same character for two wildly different things.
2 more...

I think this is a good rule-of-thumb in general. But I think the best way to decide on the correct coverage is to go through uncovered code and make a conscious decision about it. In some classes it may be OK to have 30%, in others one wants to go all the way up to 100%. That's why I'm against having a coverage percentage as a build/deployment gate.

1 more...

I would add Ars Technica to that list and call it a day.

For programming I follow YouTube channels of the conferences relevant for my tech stack (YouTube natively supports RSS). They are generally 1 hour talks but it's a great way to stay up to date.

  • Linus Torvalds
  • Kent Beck
  • Dylan Beattie
  • Ian Cooper
  • Simon Brown
  • Martin Fowler
  • Daniel Terhorst-North
  • Sam Newman
  • Andy Hunt
7 more...

Would love to see a browser based implementation of this.

Is Red Hat trying to kill downstream clones?

We cannot speak to Red Hat’s intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.

The answer is "yes". IBM is being IBM. They bought CentOS and hoped that would be the end of it, but then Rocky and Alma appeared. I don't know why they didn't foresee this happening.

3 more...

This question is probably a better fit for !learn_programming@programming.dev community.

I think single account ActivityPub implementations are addressing a weakness of the Fediverse: one's identity (handle, username) is tied to an instance they have no control over. If that instance shuts down users lose everything. With a single account instance, you take that control back. And since it doesn't need to scale the architecture can be much simpler and can be deployed to much cheaper infrastructure.

The demo was not straightforward, though. And I didn't quite get how a user can follow Mastodon users, for example.

I'm not sure it's that simple, really. And I definitely don't think this is limited to Windows. I agree with other comments that this is mostly related to complexity. The more complex the domain the more difficult it is to implement/maintain a good solution. Delivering the new shiny feature is more exciting for all people (product management, development, users, etc.) than to fix bugs. And if you don't have the resources/maturity to keep technical debt under control, the software quality will suffer over time. Free software may be the exception here as profit is not always the primary concern.

1 more...

Thanks. I didn't know that when one adds an image it would override the URL. Even though the post contains the URL, clicking on the title only shows the image. I included the URL in the post body, but it's not as visible, unfortunately.

1 more...

Did you take a look at write freely or other blogging software with native ActivityPub support?

3 more...

In 2014 Robert Martin claimed that number of developers doubles every 5 years and says:

As long as that growth curve continues there will not be enough teachers, role models, and leaders. It means that most software teams will remain relatively unguided, unsupervised, and inexperienced. [...] It means that the industry as a whole will remain dominated by novices, and exist in a state of perpetual immaturity.

Not sure if the data can be confirmed or not, but if that's the case it will be difficult to maintain the best practices in our industry.

I don't know what the mods think about your arguments, but I agree that posts that already have a community should be posted on their respective communities and not here. There may be exceptions where certain language/tool related thing may be relevant for a larger audience, but those are probably rare cases.

I would definitely have the "Vital Contributor" badge if it existed.

Unflushable Cache

[...] Other implementations, such as hand cranks in memory caches or even caches provided by mainstream frameworks will not expose any cache management tools. This leaves ops with the only option, to restart the service to flush the memory. (Or worse, know enough about the cache implementation to find it’s location on file system and clear it out manually.)

This is a mistake I have made. It's easy to overlook during development but difficult to handle afterwards if restart is not trivial.

And because Windows and it’s eco system of applications he listed gets worse, he extrapolates this to all software.

They admit that bias in the article:

[...] since I've always been working in the Microsoft tech stack, I use a lot of it. Thus, selection bias clearly is at work here.

Now, I mentioned free software as the exception. I don't have any data as to how big free software vs proprietary software. But I think his points extends at least to other proprietary software and is not limited to Windows.

Some software get better, some get worse.

I can agree with that.

-1 is what you get back from fork() when it fails. Normally, it returns a pid_t which is positive if you're the parent, or zero if you're the child.

-1, when handed to kill() on Linux, means "target every process but myself and init". Therefore, when you take the return value from fork(), fail to check for an error, and later hand that value to kill(), you might just kill everything else on the machine.

Great story.

Please also consider posting to !challenges@programming.dev

1 more...

I wasn't aware of that. I guess it was thought to be a mod driven community. Anyway... Cool question. I hope we will see some creative solutions here.

I think, in the short run, they are hoping some percentage of Rocky/Alma users will migrate to RHEL. I don't believe they are really thinking about the long term.

https://www.overheid.nl/english

Overheid.nl is the central access point to all information about government organisations of the Netherlands.

This looks really interesting. Getting type safety and editor support to configuration may change quite a bit of how things are done. I don't know if it will gain traction, but if it does, it may really help bringing some long awaited structure to all those YAML files. There appears to be examples specifically for Kubernetes (https://github.com/apple/pkl-k8s-examples).

I agree that this is a challenge. One needs to slice the domain such that it can be covered this way. But this also means more people. In my experience, moving from "activity oriented" teams to "business centric" teams require an increase of the headcount.

I just learned about Pkl, so take this with a grain of salt. JSON Schema and Pkl seem to have some overlap. But JSON schema is not specifically designed for handling configuration and Pkl supports other formats like YAML.

4 more...

Most of the time 100% code coverage is just a waste of time.

I think you are highlighting an important point that are missed by other commenters emphasizing the developer. I prefer GPL over MIT license. But this is a possible fallback if Redis decides to change its licensing (like several others did).

I think these kind of products have strategic significance for MS for their Azure offering. They are probably preparing to offer this there (in addition to and as an alternative to Redis). So, it makes sense for Microsoft to release this with an OSS license (otherwise no one will adopt it).

Are you interested in working on a text editor? If so, I have an idea I plan on implementing myself for fun: a clone of HeyNote with some added functionality. HeyNote is a simple buffer that consists of blocks. It's useful when you just want to note a simple block of text (an SQL query, log output, test data) but you are not interested in structuring it. What HeyNote lacks is the ability to add title and tags to blocks. It's not an alternative to other note taking applications. It is just a buffer with unrelated blocks in it.

Ok, maybe I misunderstood your question. I though you were proposing # instead of $ sudo and I meant to say that being explicit is better.

I was upset when Reader was killed. But looking back and seeing what Google has become over time, I think it was for the best. Now we have entire companies that only do one thing: RSS, and they are good at it. If Reader was still a thing, I'm afraid it would have extinguished RSS.

Names matter, and Reader told everyone that it was for reading when it could have been for so much more. “If Google made the iPod,” he says, “they would have called it the Google Hardware MP3 Player For Music, you know?”

This is funny, but I think Reader was a good name. At least it reflected what I want to do with the product.

Thanks for sharing this talk. I watched it a few day ago and thought of sharing, but then forgot about it. As pointed out in the video description: "Email is too big to change, too broken to fix... and too important to ignore." The bit about the first marketing email was interesting (video timestamp) and is relevant for our times.