I agree it's totally worth it! I'm lucky that I have just enough free time to debug these things and I work with a few excellent Linux devs who have helped me with a few things.
Thanks for understanding the spirit of my point about the shortcomings above and I really like the way you phrased the "Windows has its issues as well, they're just different ones" - and I completely agree there.
With Windows you need to navigate the Microsoft account, files getting stored in OneDrive, updates happening outside your control (arguably a good thing for most users), and more that I'm sure I'm not thinking of.
I do think the Windows issues are more abstract like security, privacy, and default on features - while the Linux ones tend to be more in my face usability ones. Again agreeing that choosing your hardware and desk/laptop setup can alleviate many of things. But that requires knowing ahead of time and people switching in reaction to something Windows is doing don't get that benefit.
I guess I'm writing all this because the idea of a Linux distribution working perfectly on most/all laptops really excites me and I think being candid about the shortcomings yet providing support to the distributions is how we can get ace these fit and finish issues.
Food for thought for anyone else reading this - the end goal of Linux for everyone is why I don't get too worked up about snaps. If they get to a point where I can tell my mom she can safely install apps X, Y, and Z by pointing and clicking in the app center it's a great computing future.
In case anyone wants to point me in the right direction or give me some pointers, I’m a lifelong windows developer who switched to Linux (Ubuntu 24.04 lts) on my personal desktop and a laptop (I’m fully in on the switch) and it’s not great.
I think we need to accurately represent the shortcomings so people who switch aren’t surprised.
So far those are:
1. Laptop - Battery life is bad compared to windows. It’s about half.
2. Laptop - sleep doesn’t work.
3. All - multi-monitor setup with different pixel scaling doesn’t work for many applications.. unless you dig into all the Wayland options and issues and figure out how to launch all these apps under Wayland.
4. All - In general Wayland vs X issues. I can’t screen share with zoom.
5. All - Bluetooth driver issues - my Bluetooth headset won’t connect as an audio input and output device at the same time.
Now to be fair, I think all these are okay trade offs but they are a conscious choice. If you have anything outside a standard one monitor, wired peripherals setup you will probably hit issues you need to debug.
I started paying for Ubuntu pro to put my money into it, so I’m hopeful for these kinds of things in the long term.
Thanks for the info. Using different containers for build and test vs the packaged app makes a lot of sense.
> easier if you don't have to worry about compatibility with the target environment.
I develop on Windows and deploy onto Windows right now, and as we get everything onto .Net Core (and maybe eventually) Linux I'm thinking the same thing. If I can build/test/run my app and service on the same target OS it can only make life better.
Any good guides for this or am I overthinking it and anything on containers will work?
I like Black and Pylance, which is backed up pyright. Pylance and VS Code for dev time analysis (even though it has a few annoying issues like auto-importing the wrong paths) and pyright for "build" and test time analysis.
I set black to a longer line length like 100 or 110 depending on who I'm working with. Black makes sure everything has consistent formatting.
Sorry for focusing on such a small part of your comment. I’m learning about language design (as much as I can) and I don’t really understand what you mean by “double dispatch like Python”.
I think (maybe soon thought) that Python has single dispatch. Since you’ve invented languages and work on them I’m pretty much 100% sure I’m wrong and would love to learn why.
I read https://en.m.wikipedia.org/wiki/Multiple_dispatch and came to the conclusion Python has “single dispatch polymorphism” because the method resolution is based on the type of the calling object dynamically at runtime and there is no method signature overloading, which means the argument type(s) doesn’t play a part in picking/resolving the method to be called.
If you have time, do you mind explaining or pointing me to some resources?
It's native, really really fast, supports regex, and has nice defaults. The only catch is you need to understand its default ignores if you're working in a git repo.
Thanks, this makes a lot of sense. I'd like to think I was slowly closing in on this. Mine isn't as clean as what you put but I made the data within each of the enum possibilities a discrete struct.
Explaining my experience - I haven't done any hardware or firmware programming besides messing around with Ardunios. I have written a low amount of C (tiny VM for toy language) and a moderate amount of Rust (a couple thousand lines for various projects, mostly console apps that needed to run fast).
It sounds like you have some experience in this and I have been curious for a long time why Rust can't or doesn't run on almost every micro-controller? Is it based on the compiler? I thought that because Rust has no runtime/produces a binary which does not require a runtime that as long as the Rust compiler emits the right backend instructions it should just work?
Adding to my confusing, I think rustc uses LLVM which is a way of separating a language's frontend from the backend code emitted, so I thought any micro-controller supported by LLVM would work for Rust.
There is a low probability I would rent a space like that. If I lived somewhere close enough to have deserted woods (where there could be multiple cabins with trails) within a 20 or 30 minutes drive I think that implies a low cost of land.
If that's true my first priority would be to have either a house big enough for a separate office or even enough land to have an office shack or floor above my garage. A separate work cabin that involves a commute doesn't make a lot of sense to me.
It's okay if you just didn't go into detail but I don't see anything about a kitchen, and the remote location kinda implies there isn't anywhere nearby to get food. Nothing nearby is totally okay as long as I have somewhere to make or at least reheat food. Firepits aren't enough if they're the only method of cooking because it can be pretty gnarly outside and I don't want making lunch every day to involve making a fire, dealing with rain, and getting smoky.
I completely agree. Because I think this area is really interesting I'm going to add a few more thoughts.
The first web service I built used a table inside the production database for structured logging and I had one kind of log event that I just included more and more in over time, using empty fields when needed, which ends up being an anti-pattern like a god class. That wasn't terrible, I could filter for the logs I wanted by including a statement like RequestId IS NULL.
The biggest problem I have seen with using a table in the DB and not a completely separate DB, is if it's a traditional relational DB (I'm sort of making up that term to refer to systems like MS SQL Server, PostgreSQL, MySQL) the schema is static, and each table can only contain one type of log or event unless you stuff it all into a dynamic-ish column type like JSON or XML (ewww using XML as a logging format).
If you have multiple log formats or types (with the type system meaning of types) you need to use multiple tables to keep the filtering easy. An unintended bonus is that joining across tables in a relational DB is far faster than joining across events types in the other logging systems I have worked with.
I guess I'm trying to say you should consider using a separate DB once you have more than a few log types (which are different tables in the prod DB), which still 100% backs up what you said.
Start off in the prod DB and move it if and when you need to. In the worst case scenario you can do unstructured logging with like 4 common fields (LogCreationTime, LogIngestionTime, RequestID, HostName) and a message field and use that until it doesn't work anymore, and then you have a service that is complex enough to warrant spending more time on the logging.
Really easy and good homegrown logging. Use a structured logging library, this is key because it lets you easily filter on the properties attached to a log event.
Then log those to a database. If you don't have a ton of volume and want to use really reliable tech and be safe(ish) send your logs to a relational DB used only for logging. I have never tried sending to just a separate table within the production database but I know that can be done too.
Create read-only users on that logging DB or table.
Download a GUI client for that DB and you're up and running. You can use SQL to filter, order by timestamp, and create views.
If you still want to stay homegrown it's straightforward to put an API in front of it that powers some dashboards or easy investigation tools. For example, submit correlation/request ID and get back every log event in-order for that, color error logs red and boom - 1st level data visualization for investigations done too.
It sounds like you are understandably worried about it going down. Standing up another copy is a great idea, and a great exercise in making sure your company understands how to build and deploy it from scratch.
When you do that you also need to figure out the data persistence layer. You probably want to either share it between both instances of the application or setup a backup/copy system so the version in the cloud has up to date data and is more of a hot spare than a second set of infra lying around with an empty DB.
Moving on from there, if your only goal is to keep it alive while the devs are on vacation, you should probably implement a deployment freeze. Yes in an ideal world you would make any and all changes to an infrastructure as code template and re-deploy, or at least change config files in a repo and re-deploy those but it sounds like the application isn't that modular.
Most incidents are caused by change, so minimize that until the whole team is back together, including the devs who wrote the service, to start making improvements.
At the same time you need to know or figure out how you can change config to keep it running. Ex: You need to update a cert thumbprint or change a timeout value. It sounds like it's either running on bare metal or on VMs on a physical server you own? If that's the case maybe sshing into the boxes to manually edit config is the least bad way of updating it (again - only until this emergency situation is over). If you go the route of ssh-ing, at least build a tool or script to update the key value pairs in your config store so you don't missing an angle bracket or quote and set your whole system on fire.
If the developers weren't going on vacation my advice would be a lot different. What I have written above is purely tactics to keep the system alive and the business making money until it's a better time, personnel wise, to improve the system.
Lastly for some dev advice, get started on some end to end or "pinning" tests. Yes they are typically the most fragile and slow type of tests but you can get a lot of safety and peace of mind from just a few of them. I personally feel that in situations like these they are the best value per dev hour spent.
If you're using Python, introduce mypy immediately. Same for JavaScript (use TypeScript). Being able to lean on a type system (or if you're in a static language - compiler) when refactoring or making sweeping changes it incredible helpful and lowers the chance of making a mistake by a large amount.
If you want more, I have tons more I can write on this subject but this is getting quite long :)
If I have read his example correctly - he's not modifying the object he is looping over. car_ids is externally defined and he is using a loop to exhaustively test other objects and take an action on them, which is adding them to the externally defined array.
I do agree with what you are saying, don't modify the enumerable you loop over. IIRC C# is pretty safe in that it doesn't allow modifications to the enumerable inside of a for loop or foreach loop.
I think it's interesting people say functional constructs like map don't involve looping. They do, it's just hidden from the caller of those functions.
Hey, I use PowerShell on Windows a lot. Some advice that I hope helps for installing posh-got specifically is to “git clone” the posh-git repo. Then in your $Profile.CurrentUserAllHosts do an Import-Module for the PSM.
I know all this is personal and subjective. I think using git to manage this is pretty easy and safe. If and when I want to update it’s as simple as doing a git pull in my local repo of posh-git and reloading the shell.
If the new version is broken (has never happened yet but ya know.. in case) just checkout the previous one.
I have found using git, the powershell user profile and modifying my user path when necessary is the best way of managing dev dependencies on Windows.
I also understand why people want this all abstracted away from them in a package manager.
It's too easy as a catch-all to say "everything can always be priced in". Right now 48 states (I can't find anything saying all 50) are in a state of emergency, which prohibit raising prices more than around 10% or 20%.
I'm bringing up these points because over the last month I have come to also think either state or federal government needs to take responsibility and buy these makes from a local producer - even when there is no pandemic.
I don't think our connected web of hospitals, suppliers, and insurance companies have the right incentives to use local, "expensive" suppliers when there are lower cost non-local suppliers and these non-local suppliers have stocks.
I think what happened to the popularity of .io domains could.. maybe.. be called a fad. I think that doesn't dig deep enough. It came on the scene and was popular with technical services and startups because it sounded techy and cool and short names were available.
When I did personal research about domain names I found people in the US are familiar with .com first, .org second, and everything else is a distant 3rd. While I'm cherry-picking an old quote from a PG essay [1], the stat he provides is pretty interesting. It really drives home how important owning a .com is for easy discoverability of your online presence.
All of this is in addition to the ethical and security issues the posted above listed.
Quote > 100% of the top 20 YC companies by valuation have the .com of their name. 94% of the top 50 do. But only 66% of companies in the current batch have the .com of their name. Which suggests there are lessons ahead for most of the rest, one way or another.
Thanks for understanding the spirit of my point about the shortcomings above and I really like the way you phrased the "Windows has its issues as well, they're just different ones" - and I completely agree there.
With Windows you need to navigate the Microsoft account, files getting stored in OneDrive, updates happening outside your control (arguably a good thing for most users), and more that I'm sure I'm not thinking of.
I do think the Windows issues are more abstract like security, privacy, and default on features - while the Linux ones tend to be more in my face usability ones. Again agreeing that choosing your hardware and desk/laptop setup can alleviate many of things. But that requires knowing ahead of time and people switching in reaction to something Windows is doing don't get that benefit.
I guess I'm writing all this because the idea of a Linux distribution working perfectly on most/all laptops really excites me and I think being candid about the shortcomings yet providing support to the distributions is how we can get ace these fit and finish issues.
Food for thought for anyone else reading this - the end goal of Linux for everyone is why I don't get too worked up about snaps. If they get to a point where I can tell my mom she can safely install apps X, Y, and Z by pointing and clicking in the app center it's a great computing future.