They usually perform well, but get put in a drawer and forgotten about because the software compatibility is generally atrocious. Peripherals advertised generally never work, but you know, might in a future kernel. I've been burned enough that I've sworn to never buy a SBC no matter the specifications.
That's good to know, thanks. I've had pretty good luck over the years with ordinary RPis (I keep a couple around for random projects); the most serious problem I ever have with them is the long-standing one around slow SD card corruption.
The RPI is sort of the exception; I have a couple of them doing odd tasks around the house like displaying security cameras, but that's an outlier due to the massive amount of support it gets.
In boxes in the basement are all sorts of SBCs, from the original A10 Cubieboard from 2012, to many Hardkenel boards, to all sorts of bizarre barely operational SBCs from various sources. They all had the same issue of being basically unsupported unless you made it your life goal to dig through obscure datasheets and compile kernel patches from some forum post you found.
A good holistic replacement for the RPI is the APU2, a x86 board of similar cost that has a bunch more peripherals, real support for booting from SATA, ECC memory, and that sort of thing. Absolutely no video support, but I have years of uptime on the things with no issue.
Thinking about how much ewaste all those clone sbcs must amount to makes me sad. I fell for some pi zero clone too about three years ago and it ended up the same. Meanwhile my original pi (the 512mb variant) is still running Kodi on my main TV.
> Upon successful submission of a package, the package maintainer will receive an NFT to evidence their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards.
I want literally nothing to do with a cross between a binary distribution tool and a cryptocurrency pump and dump.
It doesnt seem we're far away from any mention of "cypto" being a reason to flag (/ report spam).
As the economic recession accelerates, one of its few joys will be the charlatans paying on super-easy-mode being exposed for the useless players they are.
I feel that the major cultish hype-cycle of the last decade is rolling back, and my stress levels are dropping.
Many tech companies are both unprofitable and contribute near 0 value to society. Not unique to crypto. Be careful what you wish for, or the only people left paying software engineers might be non technical companies who pay $80k a year.
Programmers provide high economic multipliers on business activity and are typically in a good position to extract a proportionate reward for doing so.
If we kill off that group of people earning 300k+ in unproductive businesses, all the better. I'd prefer that money be invested in more productive tech, and i'd suppose would generally raise salaries -- since atm, ex hypoth., it is just being burnt
I'd definitely prefer this outcome but I have a feeling we're going to go right back to where we were before as soon as interest rates come back down. Big tech starts aggressively overstaffing again while VCs pour money into mostly useless garbage. I've been doing this for awhile now, mostly in the startup space, and I'm not even sure if VCs care if there's even a viable business there. It often feels like a legal way of running what effectively amounts to a ponzi.
Given home prices are what they are now, I don't really think it's reasonable for mid or Sr level engineers making less money than what's required to afford a mortgage
LMAO the supply chain attack potential is epic. Oopsie the author of leftpad clicked the wrong button and now an unknown entity owns their package and just updated it with malicious content!
No such a thing as a buggy smart contract. The contract is right by definition, and that is what was agreed upon. Therefore, it’s the humans who signed it who are buggy. Or something.
I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.
The first thing I was ever taught in my formal CS education is that the computer is (nearly) always right -- if there's a bug it's the programmer's fault. How is that not the case with a smart contract? How is that not the case in the real-world when there are loopholes in laws and contracts? Obviously you can always ask the courts for remediation in the real-world, but let me please point you to many examples where courts make an incorrect/unreasonable decision.
> I'm a bit confused. What you said is factually correct, but you're coming off as though you disagree with it.
It is factually correct, and I also have an issue with it, yes. “There can be no bug in a smart contract by definition” is at the same time true and ridiculous. My problem is using this as contracts, which are agreements between two faillible human beings. In reality, mistakes are everywhere and we have fairly robust ways of dealing with mistakes in contracts. In contrast, what would be a bug in any other situation becomes the truth, with no recourse. This is typical of 2 fallacies in some tech circles: every problem has a purely technological solution, and we don’t need those old fashioned real-world institutions.
Smart contracts are a very fancy hammer when we’d need a screwdriver.
OTOH, I don’t have anything against willing participants having fun with smart contracts.
How does creating this NFT cause it to have value, and therefore reward the package maintainer? If the issue is that no one is putting money into the system, the solution can't be a more complicated way of ensuring that the non-existent money goes to the right person.
The website linked, and it's associated information all absolutely scream red flags and is functionally similar to a hoard of other schemes. It's a technically simple product (distribute binaries from a webserver) with a completely arbitrary cryptocurrency stuffed onto the side, allowing for bombastic, buzzword filled claims which just defy reality. It attempts to promote itself by driving users who will get some form of profit sharing as part of their participation, promising some sort of rewards paid by the creator.
> Package maintainers will publish their releases to a decentralized registry powered by a Byzantine fault-tolerant blockchain to eliminate single sources of failure, provide immutable releases, and allow communities to govern their regions of the open-source ecosystem, independent of external agendas.
It's existence is an attempt to justify the creation of yet another cryptocurrency, not as a serious solution to any problem that exists in distributing software.
Keep in mind that this scheme wouldn't reward the authors of software -- it rewards the people who create and upload packages. Those usually aren't the same people, and the maintainers that are most subject to burnout are the authors, not the packagers.
It also appears to require those developers to purchase (or otherwise acquire) tokens before adding software to the packaging system.
> Keep in mind that this scheme wouldn't reward the authors of software -- it rewards the people who create and upload packages. Those usually aren't the same people, and the maintainers that are most subject to burnout are the authors, not the packagers.
It creates an incentive to package software for the ecosystem, which is a pretty good goal to achieve for a package manager -- especially a brand new one where it would be hard to gain traction without a large number of packages.
I see that as mainly a social problem, not a technical one.
I've noticed that a lot of crypto enthusiasts tend to reach for technical solutions without understanding the social causes of the problem in the first place
Those people are already getting paid in GitHub stars. Adding United Fruit Company dollars to the mix doesn’t make the compensation any more real.
What money will be entering this ecosystem? Absent funds flowing in, how will package maintainers be able to convert their tea bucks to something they can pay rent with?
Yeah those GitHub stars really help with burnout. When you're wading through a hundred pointless PRs of people trying to pad their contribution stats, those GitHub stars just release all the tension.
I think a bias against crypto is clouding your argument. Reading the whitepaper makes me wish Bitcoin had never existed, given I imagine plenty of people would apploud many of the ideas in it.
With all the flaws of npm, people do want to be able to have a immutable, mirrorable package-repository with a trust framework they can independently confirm. This does that, along with clever extras like "tasters" who stake a certain amount of value before confirming a package does x.
It's.. sad, that any tech that uses blockchain is now doomed to flag-death because of everything. I get it, but can't help but wonder how I'd have felt reading this paper 10 years ago.
I don't doubt that the author if tea is well-meaning, I think the issue is how it's going to get used, which is what the other poster was referring to.
On top of which I want literally nothing to do with Max Howell. He's the consummate brogrammer douche. Whined about getting asked to do a code exercise at a google interview, bragging about how he made a project in use by X percent of the company's engineers.
He should go to a few conferences, introduce himself under another name, and bring up brew. I'd guess after half a dozen encounters he'd stop incessantly bragging about being the creator of brew.
Everyone uses brew because they have to, not because they want to.
I'm torn between the brew team being full of insufferable people because they don't know this, and arrogant because they do know it...
> Everyone uses brew because they have to, not because they want to.
What?
Homebrew is easily one of my favorite pieces of software. It's the first thing I install on any new macOS or Linux machine.
Almost every piece of software I want to install is easily installable via Homebrew. The versions it has is almost always more up-to-date than what's in apt or yum. On macOS I can install all of my GUI apps with Homebrew Cask.
I have my Brewfile with my dotfiles so that any time I get a new machine it's easy to install everything I need. Just this week I updated my dotfiles to install Homebrew + my common development utilities on GitHub Codespaces. Without Homebrew I'd have a long, long, long script downloading packages from source verifying keys, installing dependencies, and then finally installing some software.
Aside from that, there are alternatives to Homebrew. Install things yourself from source, or use MacPorts.
> Whined about getting asked to do a code exercise at a google interview, bragging about how he made a project in use by X percent of the company's engineers.
My guess is that you support the status quo of software engineering interviews. That's fine, but many don't.
Why do you have to use brew - there are other package managers for macOS new ones like nixpkgs and ones much older than brew like Macports and Fink. All of these follow normal Unix standards e.g. like work on a multi user system.
Because Homebrew is unfortunately "the standard" and the first place a project will package for if availability for macOS is desired. As a Linux user, it's the worst package manager I've ever experienced but it is what everyone is using in my company who uses macOS (most people).
"pull requests for new packages are welcome" is the self-defeating answer: if you as a user have to create a PR for a package to be in MacPorts then it means that MacPorts have not attracted enough attention from the authors of the package to submit it themselves.
In the Nix world, at least, packages are often added by people who want to use them. I think that's more common than the fulfillment of a packaging request.
It would be funny if the state of packaging on Linux would not be so pathetic.
If authors care about Windows they do produce Windows installers and/or publish it in their store.
If authors care about macOS, they produce .dmg or publish the app via Mac Store. Additionally they often publish it on Homebrew.
If authors care about Linux, they provide packages for Ubuntu and Fedora, and sometimes for more distros from the long tail (usually Debian comes 3rd as it is simple to add after Ubuntu).
It's so slow: on the order of single digit minutes to a dozen to install a single package. It feels messy, like it's shotgunning my entire system with bits of itself (I don't know how true the reality of this is). I've not infrequently had packages simply fail to finally resolve after they did their dance of resolution. It does not inspire delight. The vibe, if you'll excuse me, is very crude cudgel.
Oh, the install location it asks you about when installing Linuxbrew is extremely odd. One choice offered is to make a dedicated brew user directory and then install there? That's terrible practice. No one else does this because it's terrible. And then the other apparently breaks a bunch of stuff and is not recommended.
You don't absolutely have to use brew, but there's a sort of relentless soft pressure to use it because it's more or less the de facto standard package manager for macOS and has such a large collection of packages.
I rather dislike it, and I periodically purge it from my system. So far I've always ended up reluctantly adding it back because I was trying out some tool or other that was dramatically more of a pain to install without brew.
I can get by for a long time without it, but then I want to try out something that assumes brew, or whose dependencies assume brew, and it winds up back on my system again until I get vexed enough to remove it again.
> it's more or less the de facto standard package manager for macOS and has such a large collection of packages
I definitely see the social pressure. That said, I’ve never needed to use it because I needed a package that was not on Macports. So far for my use no difference in the number of packages in the default repositories has been meaningful.
The thing that always makes me cave and install brew is I want to try some tool and its default install assumes brew.
Now, I'll bet in close to 100% of cases I could get things to work with stuff from MacPorts instead, but I've accumulated thirty years worth of scars that incline me to want to stick as closely as possible to the defaults when trying something new.
So I end up going back to brew, even though I don't much like it.
> [Max Howell] should go to a few conferences, introduce himself under another name, and bring up brew. I'd guess after half a dozen encounters he'd stop incessantly bragging about being the creator of brew.
I share your opinion of the technical execution of Homebrew— probably anyone with a deep Linux background would. But I think Howell is well aware of those deficiencies by now (and many may even have been clear to him at the start).
I also think that it's worthwhile for us haters to take seriously what Homebrew gets right, and that means admitting that it's a tool that many, many people have experienced as pleasant and useful. The tidy subcommand interface, relative simplicity, choice of popular/trendy tools (Ruby, at the time of Homebrew's creation), inviting and consistent (if controversial) use of metaphor, and playful tone (small jokes on the docs, use of emoji in CLI output), are all things that have proven to make a real difference in Homebrew's success. None of those speak to package management fundamentals, but they're real strengths and they are visible to all users of Homebrew right away, whether they know much about package management or not.
I feel you about being basically forced to use Homebrew, though. That sucks. It's frustrating to feel hampered by the tools your team uses when you know there are better ones out there but you just can't reverse the team's inertia.
I also like brew. The whole UX pipeline is smooth, and I don't mind if it takes an extra 30 seconds to install packages (which doesn't happen often).
The brewfile (as someone mentioned) is super convenient, and the fact that I can use the same package manager for mac and linux is nontrivially awesome.
To be fair this is kind of a cool idea which is to allow open source package maintainers to earn based on popularity, the incentives here seem interesting at least.
However I highly doubt the original intention behind the NFT collaboration was altruistic to begin with.
Meaning at this point I don’t really trust any altruism in crypto in general (“hey we’re not trying to scam you we really are trying to change the world”).
The idea itself though was interesting to me: getting paid on a token based system for maintaining your open source package
Didn't find any reference in the readme, but was almost sure it's crypto-related the moment I saw the header image; the silly design style is so endemic that it simply shouts crypto on the visitor's face.
We left them because of this. Long overdue move away from Gmail Gsuite resulted in TS costs for our dozen user team at least doubling; the overhead involved in managing the overlay network acls was also getting out of hand too.
GNOME isn't even a fraction of the problem, desktop linux is absolutely unsuitable for day to day use and that's nothing to do with the desktop environments. The foundational design decisions of the way applications are rendered in linux means that every experience is inconsistent, nothing even has the same file picker and it's always a surprise to see which one is thrown in your face in any given situation. This sort of inconsistency is ripe throughout every part of linux, everything works so long as you make it your full time job to work out what the incantation is to enable basic convenience features.
Feels sort of nonsensical honestly. Credit card anti fraud is entirely reactionary, there’s no magic bullet, you’re just papering over the cracks of an absolutely broken payment system. Every service will see different fraud, it will always be changing, there’s no one fits all solution. Very frequently the “rules” of the systems aren’t solid and everybody trying to exploit them knows that.
It piqued my interest enough to google it and it seems like it’s actually a notable thing in the online betting world and is indeed fairly sophisticated and purpose-built.
See below for the full quote from the canadian website, but CAD$24,057 per year is the canadian cost threshold so yeah, it'd be just barely disallowed. The $120k number you may be thinking of is a five-year average.
Plus side, "spouse" is explicitly listed as an exception, so I guess it's somewhat less disgusting now that they're at least not using disability as the reason to keep people's spouses and children from reuniting with their family in Canada.
Which drug is the leading/where'd you find the info? I believe you, now I'm just curious about the Canadian health systems' treatment philosophy + how it differs (if at all) by province.
Wow. In the US the list price/general price is ~68k annually or ~17k per infusion. (Of course this isn't what people pay, but for 'cost to the system' metrics, it would be the apples to apples comparison).
Nothing near my number, which is encouraging. My numbers are clearly somewhat out of date. But I do wonder where that extra 40k+ cost (depending on currency values) in the US comes from.
Yeah, the whole thing where the drug manufacturer pays for your copay is a bit infuriating in how it sets up such horrific incentives in terms of price-to-insurance. Tecfidera was just dimethyl fumarate, which you can buy in gallon quantities for pretty cheap.
That is why it is more expensive in the US. The patient rarely pays for it, so the insurance companies make it comically expensive and then the insurance pays for it up to a deductable and then the MANUFACTURER pays the copay for you. It's really, really stupid incentives.
Literally with Tecfidera I would burn through my annual deductible so fast that I didn't have to pay for any other medical procedures after the first three months of a year. But out of pocket it was free because of these incentive plans. It was freaking dimethyl furmarate, and I'll grant them manufacturing and formulary costs, and trial costs, but clearly there's more than just that going on.
But yes, Ocrevus and Kesimpta (both are monoclonal antibodies that reduce B-cells, and leave you immunosupressed -- I got 5 covid vaccine boosters, two rounds of monoclonal antibodies to boost my immune system, and still got COVID last month) are as far as I am aware the state of the art for drugs.
Personally I think the idea of somehow treating an underlying EB infection while also doing other treatments is the most actually encouraging news I heard out of MS research since Ocrevus.
In any case, FWIW I did more research on that site and it does actually list "spouse" as excluded. Since other people may also have rather panicked after hearing about this I have copied it below wholesale.
---------
Excessive demand cost threshold
2022 cost threshold (under the temporary public policy)
$120,285 over 5 years (or $24,057 per year)
This is an amount that we use to decide if the cost of your condition places an excessive demand on Canada’s health and social services.
In June 2018, the Government of Canada announced changes to the excessive demand policy. Under the new policy, the cost threshold amount is increased. The new amount is now three times the Canadian average cost for health and social services. We’ll update this amount every year, based on the latest Canadian average.
Exceptions
Medical inadmissibility rules for excessive demand reasons don’t apply to:
* refugees and their dependants
* protected persons
* certain people being sponsored by their family, such as dependant children, spouses and common-law partners
There's ways around medical inadmissibility, you can absolutely get around the cost threshold by proving your ability to cover the cost- so long as it isn't a personal guarantee. It's sort of a nightmare, you have to apply for PR, be denied, and then there's a one time appeal process. Talk to a lawyer about it if this is your actual plan, because they know more than I ever will.
You don’t see that because it just isn’t supported by what people make. No laptops are going to provide PD power outputs at relevant voltages because they would need to have a huge amount of switching circuitry for a situation that is not strongly user demanded. Spotty support means products are never built to expect it to exist, and we continue with all the problems of USBC being borderline unusable for what you would expect to be simple tasks. PD is a bag of hurt at the best of times unfortunately.
