I do like the build of Macbooks and especially the solid casing. Unfortunately I could never get used to MacOS even within 2.5 years and it was not quite as reliable for me as it is for many others.
XCode installations failing, Docker installation failing after an OS update never to work again without completely reinstalling OS, plugging in headphones would crash the Macbook (until OS update 6 months after I got it), video calls slowing to a halt, if sharing screen etc.
Also there were some things I just never got used to in Mac like window tabbing & minimize working in a Mac way. Maybe if I hadn't had a personal laptop that used Linux at the same time, I would have gotten used to it a little better, but I just plain hated the way it worked.
To be fair, I think it was still more reliable than varieties of Windows, especially the later ones! If tabbing worked more like under Windows and it allowed a bit more configuration, I might be using Mac these days.
That leaves Linux. Although it's not flawless neither after configuring Debian + i3, it works exactly like I want and the same installation has been reliably working for 5+ years. However, getting to the setup that just works certainly took several tries and depends on laptop compatibility, so... No ideal choices exist right now I think. Just luck and what someone is most used to in the end.
I’ve used Macs nearly exclusively for 13 years and have not gotten used to the window tabbing. I just fundamentally don’t think windows of the same application should be grouped together.
I gave it a try on my current codebase out of curiosity. Definitely useful. It worked well and fast, but it has a lot of duplicates that get rendered as exports in the NodeJS modules based codebase. I think it can sometimes be caused by me just being haphazard about re-exporting them, but other times I'm not sure.
Eg authenticatedMenu() appears 4 times in authenticatedMenu.js, only one of them is imported by 2 different files and 3 are just there alone. There's a single export in the file and a number of other files import it through an index.js that re-exports several files other files too.
In my case I think it'd help, if I could disable the duplicates as they don't really provide any useful information when exploring the codebase.
Also, if there was optionally a way to ignore the files that re-export functions/classes and collapse those paths, it'd make the graph a lot smaller and more easy to understand. Maybe it's already something that depgraph does, but the duplicates confuse things, so I'm not sure.
> I think it can sometimes be caused by me just being haphazard about re-exporting them, but other times I'm not sure.
I think so too. I guess that's how your project is structured and duplicates maybe inevitable.
The graph shows exactly how the project is organized. Right - "duplicates confuse things" - this would suggest eliminating "files that re-export functions/classes" or passing an option (-i) for ignoring specific paths would help. Otherwise, this issue is noted for further analysis.
My favourite approach to documentation is the "4 kinds of documentation" - whether it's about an API, a library or anything else. I think it's a very clean way of explaining "good/poor" documentation.
In a nutshell, which type of documentation we need depends on the goal we have. Any API missing one of the kinds of documentation will feel like it is missing something. Once I read about it, I've been noticing how the documentation I like tends to have all these aspects covered.
Over a (rotary) phone with a classmate of mine, who had gotten really-really into programming, explaining how to do things in Turbo-C. Turbo-C had a great help system, so I mostly followed that and my classmate's instructions to make a tiny drawing program and a small RPG that rendered characters straight from FILE* to screen a pixel at a time.
I didn't know how arrays or linking/including worked (or that they existed), so it was one long file with each creature having its own function to determine their behaviour and their own health_creature_1, health_creature_2 and so on. I really started wondering if there was a better way after a while.
As a user, this is great news. I think that the artificial lock-in to services that have near zero cost of on-boarding and off-boarding is not what nice companies should do.
As an entrepreneur, this is amazing news! This means users can now more easily switch to my superior service.
At least this is how I choose to see it. It seems to encourage healthy competition and I'd rather compete on the service quality and value than the cleverness of my contracts and discounts. I'm sure it will hurt the bottom line of some companies, but I'm not sure it's a bad thing.
Absolutely, companies who remain stagnant will fall behind if they don't offer something as good as or better than competition. Only shareholders who are concerned about "guaranteed income" regardless of its sources will not like this imo.
... of course it's the EU. It won't be enforced against large companies. I mean, it seems to me pretty obvious that this outlaws microsoft office. And yet, it's september, and ...
Seems to me these trivially violate just about every condition talked about in this article ... yet it's still for sale with no way to cancel and get your money back. Am I missing something?
In fact this store only sells subscription software. That's the only thing available. Non-cancelable, of course. And there's plenty of technical and bundling barriers to switching.
Have you contacted Microsoft and they rejected your request? EU is not asking SaaS providers to implement a 'Cancel Anytime' button. EU is not banning SaaS providers from selling one-year subscription either.
> this article
You mean this AI slop. The OP's article has very little to do with what EU Data Act is.
I expect that in the EU, this is somehow only going to apply to small EU companies. I'm sure there's technical reasons for that, that are currently thoroughly de-emphasized, difficult to find, but that will be the outcome.
This is also too little, too late, as usual in the EU. Extremely large companies have already profited incredibly of of this.
Plus, most provisions are again people, business people, refusing to pay for software. As a software engineer, I can't say I like this idea.
From my understanding, yes. Microsoft should give {unused portion} - {operation cost of migration} back with you if they're compliant with EU laws.
Actually, I expect they'd do that. I actually contacted Adobe support many years ago to complain about the cancel fee, and they did cancel the cancel fee for me.
Kagi works for me in other languages, but only if I explicitly switch it from "International" to a specific country search. Otherwise it tends to default US results.
Even when you do that, it heavily prefers English content. Whenever I search for some hardware for example, there are several non country related results on the first page. The first 2-3 usually from the selected country, after that it’s not that great.
When I search for “sony wh1000xm5” for example, then the first 2 are from Hungary, the 3rd are a generic English sony.com page, the 4th from the country, all the others is in English and not related to the selected country at all. Austria is a little bit better, it still has generic English results, but mostly it just ignores the differences between Germany and Austria. It’s a huge pain point when you want to buy something.
I live in Bulgaria and even google is pretty bad at this, however adding the Bulgarian word for price at the end of it always worked for me both in kagi and in google
There was a book about the eels being born from Sargasso sea, all transparent at first, that I remember reading ages ago. It mentioned a lot of legends as well surrounding the eels, because the young ones were never seen - only fully grown eels.
I cannot remember precisely, but to explain their existence, there were even some recipes about "creating" eels. I think one was something similar to "put a couple of sticks under a bit of wet turf for a night". And that is how the witches were able to create the eels.
I wish I could remember the title of the book, but unfortunately it was more than 30 years ago when I read it.
The title translated to English would be something like "The Journey of Eel" by Aadu Hint. Published in 1950, so I'm rather certain it makes more sense to read the newer books these days.
Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc.
The build/deployment time difference is maybe the least relevant, but also there most of the time, because Docker performs more work than simple zip+scp and an scp copy of the version to archive somewhere. Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment, if application files are only ~1-2MB tends to add quite a few seconds to the process, although how much it matters depends on network speed of course. For example on my modest connection it'd be ~8-10 seconds vs <1 second.
There are of course great reasons to use Docker such as a larger team that needs a common environment setup or when using languages that don't have great dependency management system (eg they have non-transferrable builds between systems), but it is something "extra" to maintain.
Sure, in the grand scheme of things, though, I wouldn't argue that seconds is a legitimate slow down. I just really struggle to buy into the argument that "non-Docker" is superior and that introducing Docker is a problem. It's _another_ way to do deployments, and it's not strictly worse. There are tradeoffs on both sides, although I would argue Docker has far fewer than just using systemctl and SSH.
> Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc
Docker is available on every major distribution. Installing it once takes seconds. Accessing logs (docker logs mycontainer) takes just as long as systemctl (journalctl -u myservice). Maintaining a registry is optional, there are dozens of one-click SaaS services you can use you instantly get a registry, many of them free. Besides, I would consider the registry to have significantly more time-savings benefits due to being able to properly track builds.
> Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment
This is only partially true. Images are layered, and if the last thing you do is copy your binary to the image (default Docker practice), than it's possible for it to be exactly the same time as it's only downloading one new layer (the size of the application). Only on brand new machines (an irrelevant category to consider) is it fully true.
I think the point is that not using Docker is easier, simpler, cheaper and better than using Docker.
Unless it is not, then you should use Docker.
But many (all?) of us have had the experience of a manager insisting on some "new thing" (LLMs are the current fad of the day) and if we are not using it we are falling behind. That is not true, as we all know.
It is very hard for the money people to manage the tech stack, but they need to, it is literally their job (at the highest level). We desperately need more engineers, who are suited (I am not!) to go into management
But this assumes that Docker provides _no_ advantages in time-savings, which is simply false. The person who recently responded to me noted that themselves. There are several scenarios where Docker is superior, especially in cases with external dependencies.
My point is that the universal argument that Docker is inferior to manually copying binaries is flawed. It's usually put forward by people who fit in the narrow scenario where that happens to be true. If we can agree that both options have trade-offs, and that a team should pick the option that best fits their constraints, then I think that's pretty much where most of the world sits in thinking. There are extremists on both sides, but their views are just that, extreme.
When thinking more abstract or intense thoughts, for me it's probably more or less what you're describing? Sort of disembodied voice, at least when the focus is not on the qualities of the voice, but on the details of whatever the thought happens to be.
Although, I can also choose to listen to any thought in a voice of my choosing, if I focus on it. Then it has "real" voice qualities such as accent, pitch and tone, but without differing volume. And it always seems a bit duller than real voices. I guess that's how I would describe it at least.
XCode installations failing, Docker installation failing after an OS update never to work again without completely reinstalling OS, plugging in headphones would crash the Macbook (until OS update 6 months after I got it), video calls slowing to a halt, if sharing screen etc.
Also there were some things I just never got used to in Mac like window tabbing & minimize working in a Mac way. Maybe if I hadn't had a personal laptop that used Linux at the same time, I would have gotten used to it a little better, but I just plain hated the way it worked.
To be fair, I think it was still more reliable than varieties of Windows, especially the later ones! If tabbing worked more like under Windows and it allowed a bit more configuration, I might be using Mac these days.
That leaves Linux. Although it's not flawless neither after configuring Debian + i3, it works exactly like I want and the same installation has been reliably working for 5+ years. However, getting to the setup that just works certainly took several tries and depends on laptop compatibility, so... No ideal choices exist right now I think. Just luck and what someone is most used to in the end.
reply