And also, it's actually a complicated question. A one-man boycott doesn't do anything. If you work at a FAANG, work for a better world when you're off, and go whistleblower when they do something really evil, I find no fault in that at all.
The other consideration is that pretty much every company you could work for as a software developer is going to try to take advantage of your work. Most companies are morally bad at best and morally terrible at worst. If you discourage any good person from working there, the problem will only snowball from there.
If working at FAANG gives you the resources to support things you're passionate about, and you're willing to stand up for your values when they do something bad, there isn't a problem with that IMO.
My point wasn't that FAANG isn't exploitative (my bad if it came off that way, I didn't mean for that), it's that everywhere else is also exploitative to some degree (most probably less so than FAANG, there are definitely a few that are worse though), and that it could still be reasonable to work there for some people.
Bioinformatics isn't used only for medical research or within big companies.
Sub-topics like metagenomics, that are helpful in many areas of research, require high level of technical knowledge, that the life science people don't have.
Agreed. Just working for somebody bad doesn't necessarily mean you've given up, though. I mean, they made a movie about Schindler, and we all know who he worked for.
To whoever does that, I hope that there is a special place in hell where they force you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.
Sadly it doesn't fix the bad documentation problem. I often don't care that a field is special and either give a string or number. This is fine.
What is not fine, and which should sentence you to eternal punishment, is to not clearly document it.
Don't you love when you publish a crate, have tested it on thousands of returned objects, only for the first issue be "field is sometimes null/other type?". You really start questioning everything about the API, and sometimes you'd rather parse it as serde::Value and call it a day.
The worst thing is: you can't even put an int in a json file. Only doubles. For most people that is fine, since a double can function as a 32 bit int. But not when you are using 64 bit identifiers or timestamps.
That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.
As if I had a choice. Most of the time I'm only on the receiving end, not the sending end. I can't just magically use something else when that something else doesn't exist.
Heck, even when I'm on the sending end, I'd use JSON. Just not bullshit ones. It's not complicated to only have static types, or having discriminant fields
You HAVE to. I am a Rust dev too and I'm telling you, if you don't convert numbers to strings in json, browsers are going to overflow them and you will have incomprehensible bugs. Json can only be trusted when serde is used on both ends
'The wind keeps blowing my wifi signal away ' is more than enough information to diagnose the problem, and 'the computer forgot my password' is now a real thing since password managers started coming baked into browsers.
We are so far beyond parody of ourselves that i have no idea how the onion stays in business.
How could you be simpler than keepass? Like, there's more advanced features, but for basic function, its just a password to access a list of passwords.
...its just a password to access a list of passwords.
Unless you never thought of, implemented, regularly did and regularly tested your backup of the database. Or... try to use it on more than one device - maybe even at the same time.
That's the main problem with KeePass. It's nice to have it offline, fully under your control and out of the cloud, but that comes with some responsibilities on your end. And now think of how the average user solves this. If you're tech savvy enough, KeePass is great!
You technically only need it on one device if you don't want to be able to copy/paste or use the autotype feature. Which works fine until you lose or break that one device or upgrade to a new one and forgot you needed to transfer your passwords or delete your database because you didn't remember what it was and wanted to free up space.
And Bitwarden has scary things like "self-hosting".
Setup syncthing between the computers. If the person is not tech savy enough, they can always force the tech savy enough person they know to set it up for them. The are no problems with the tech, people just dont know it exists. Even if you don't or can't use syncthing (iOS users), you can just be stupid and put it in the cloud.
If you’re branching logic due to the existence or non-existence of a field rather than the value of a field (or treating undefined different from null), I’m going to say you’re the one doing something wrong, not the Java dev.
These two things SHOULD be treated the same by anybody in most cases, with the possible exception of rejecting the later due to schema mismatch (i.e. when a “name” field should never be defined, regardless of the value).
It gets more fun if we're talking SQL data via C API: is that 0 a field with 0 value or an actual NULL? Oracle's Pro*C actually has an entirely different structure or indicator variables just to flag actual NULLs.
Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.
Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you've created.
Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching
Only if using JSON merge patch, and that's the only time it's acceptable. But JSON patch should be preferred over JSON merge patch anyway.
Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.
If there are no humans in the loop, sure, like for data transfer. But for, e.g., configuration files, i'd prefer a text-based solution instead of a binary one, JSON is a nice fit.
What I'd like for a configuration language is a parser that can handle in-place editing while maintaining whitespace, comments, etc. That way, automatic updates don't clobber stuff the user put there, or (alternatively) have sections of ### AUTOMATIC GENERATION DO NOT CHANGE###.
You need a parser that handles changes on its own while maintaining an internal representation. Something like XML DOM (though not necessarily that exact API). There's a handful out there, but they're not widespread, and not on every language.
Honestly, I've worked with a few teams that use conventional commits, some even enforcing it through CI, and I don't think I've ever thought "damn, I'm glad we're doing this". Granted, all the teams I've been on were working on user facing products with rolling release where main always = prod, and there was zero need for auto-generating changelogs, or analyzing the git history in any way. In my experience, trying to roughly follow 1 feature / change per PR and then just squash-merging PRs to main is really just ... totally fine, if that's what you're doing.
I guess what I'm trying to say is that while conv commits are neat and all, the overhead really isn't really always worth it. If you're developing an SDK or OSS package and you need changelogs, sure. Other than that, really, what's the point?
Any standard that wastes valuable space in the first line of the commit is a hard sell. I don't see the point in including fix/feat/feat! just for the sake of "easy" semantic versioning because generally you know if the next release is going to be major or minor and patches are generally only only after specific bugs. Scanning the commits like this also puts way too much trust in people writing good commit messages which nobody ever seems to do.
Also, I fucking hate standards that use generic names like this. It's like they're declaring themselves the correct choice. Like "git flow".
You can always adapt to your how repo. But yeah, that's the point. If you can trust people to make changes on a repo then you should be able to trust them in using some kind of commit structure.
Generic names are probably used in order to crate a familiar, easy to remember, structurized commit format.
Cisco as a client tried to force ipv6 for their managed service and after an entire quarter of attempting to resolve it, we actually disabled it for their virtual address per their request. IPv4 has issues and IPv6 promises solutions, but it's not a stable platform yet. This appears ignorant but is based on truth. IPv6 is also eventually going to hit exhaustion with the frequency we spin up virtual machines, it's okay to skip a bad generation.
I'm sorry but how? We have appliances with dockerfiles, micro containers for remote controls, extensive botnets of virtual machines, centuries in the future when we have expanded into the solar system and trillions of humans all having millions of unique applications with addresses, it's inevitable to hit a finite number. When every square meter of smart road has an routable address; we will likely be rewriting networking anyways. The only players pushing IPv6 transition are networking companies because a new standard requires new hardware.
IPv6 has a total of 3.4E+38 addresses, and the entire surface area of the earth is 5.1E+14m². If we divide those two, then we find that you can have 6.7E+23 addresses for every square meter of your Saharan desert or Pacific Ocean smart roads. If civilization doesn't collapse due to nuclear wars or climate catastrophes and we actually do make it to the stars, I doubt that we would still be using the centuries-old and deprecated internet protocol.
IPv4, in contrast, has 4.5 billion addresses, and there are currently 8 billion humans on Earth. While not every of them lives in the parts of the world with internet, that number will most likely soon shrink to nearly nothing. When everyone and their dog has a smartphone, laptop, desktop, console, smart TV et cetera, that 4.5 billion doesn't seem nearly as big as it first once seemed to be.
This isn't a Y2K-scale problem that will summon armageddon if we don't solve it immediately, but our current solutions to the overflowing IPv4 addresses are well-polished hacks at best. IPv6 will ensure end-to-end connectivity for many years to come.
So, yes a few pieces of land mass tech such as smart road or solar paneling and we hit the theoretical limit of IPv6. And we currently dont need the addresses. So glad that you agree
Virtualization was supposed to reduce the overhead, not create entire DevOps departments.
Years of containerization yet no real use over make clean; make build
Wanted to deploy your app in the "cloud" anyways for a laugh? We had a tool for it, it's called rsync
Let's run a virtual container in --privileged mode, so we can manage system resources from it -- Statements dreamt up by utterly Deranged
Look at what tech interviews have been demanding your Respect for all these years.
(These are real documentation examples for how a simple virtualization supposedly works)
Sure, Java can tell the difference. But that doesn’t mean that the guy writing the API cares whether or not he adds a key to the dictionary before yeeting it to the client.
That’s the thing though, isn’t it? The devs on either side are entering into a contract (the API) that addresses this issue, even if by omission. Whoever breaks the contract must rightfully be ejected into the stratosphere.
That's exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.
Having a null reference is perfectly valid json, as long as it's not explicitly prohibited. Null just says "nothing in here" and that's exactly what an omission also communicates.
The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.
Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.
The "what do we even pay you for?" is just like with projects:
"why isn't this finished yet?"
We have to add tests and make sure we've tried to cover our bases.
"that's not necessary, if it works now, just release it"
That's not-
"I don't care, I pay the bills"
Sure thing boss.
*a few weeks later*
"This thing doesn't work"
Yeah, it's what we wanted to test.
"Well why didn't you?"
😐
I am a little biased because I've been using Debian professionally for many years now but we don't deserve Debian. It is fantastically stable and reliable and makes an excellent platform for running your services off of. If you are at all interested in offering some time and energy to the open source community, consider adopting a Debian package!
but seriously, modern FOSS distros (yes, debian is modern, damnit!) are amazingly good. you have an exceptionally high probablility of switching and staying switched.
Side note: anyone got recommendations for business software? I've started browsing the FOSS community here for ideas but I'm not sure what QuickBooks alternatives exist
A quick Google shows Quickbooks to be cloud-based accounting software.
For FOSS accounting, GnuCash exists so you could try that (it can also run on Windows and macOS).
However, it's unlikely to have feature parity so if you like the added convenience that Quickbooks offers, see if you can use Quickbooks in a browser. Being cloud-based, they would probably build a browser version before building a Linux desktop app.
If they don't and you need to run a Windows desktop app on Linux, you can probably do this using Bottles (which uses Wine and Proton under the hood, the tech that enables the Steam Deck).
I mean yeah, but specifically I'd like something built for Linux that's good for just basic spreadsheet stuff. I'm an electrician so I mostly just need to track jobs and accounts.
Most of (what we call) Linux OSes are formally GNU/Linux. GnuCash is as close as it gets to "made for Linux". If you don't want an accounting-specific application, but just generic spreadsheets, check out LibreOffice.
I highly recommend GnuCash for accounting though: a fellow board member cleaned up an org's accounting by putting it all in GnuCash, where it was a bunch of error-prone Excel sheets before. That really made it easier to keep track and to do it right.
The best accounting software will be the one your accountant uses.
When clients are on the same platform that I use internally everything just matches up and it's beautiful and elegant and amazing.
When clients are using something else it just doesn't fit our workflows and it's just more of a fuck around, which of course the client gets charged for.
That's how I feel about arch, it's not "stable" but the few issues I've had they typically have it fixed with an update within hours.
I do have to clarify when I switched to arch from windows my entire computer was brand new and practically no other distro booted or if it installed it dumped me to a black screen.
After running my server on archlinux with the stable kernel for 7 years I did install Debian on my new server. Zfs just required an older lts kernel than I could get on arch without a ton of hassle. I didn't need it on my Mac mini with an external hard drive plugged in. From my experience it's not very different to maintain compared to arch but it's nice having built in automation instead of writing my own.
Man it's weird using a system of what I can guess is a bunch of bash scripts on Debian to set things up compared to just using the tools built into and written for systemd.
"stable" in this case means that it doesn't change often. Debian stable is called that because no major version changes are performed during the entire cycle of a release.
It doesn't mean "stable" as in "never crashes", although Debian is good at that too.
Arch is definitely not "stable" using that definition!
Yeah, I know the definition. I knew someone would quote it verbatim, someone always does. I quoted it because it's not the word I would use. I like scheduled or versioned releases better but someone always disagrees with me. As far as I've seen it's a major/minor version release cycle anyway.
Programmer Humor
Active
This magazine is not receiving updates (last activity 0 day(s) ago).