I'd get behind that, but it won't happen at this point.
I would like to see abolishment of speculative property ownership. You either use it, or it gets given to someone else.
You can't hold it and wait for the price to go up. You get a year, maybe two, and then it becomes public domain to anyone that will use it.
I find it absurd that people are born and indoctrinated to believe that because someone else says they own this bit of land that they've never used, no one else can use it.
People are literally born homeless. Their parents may have a home, and they may let their children use it, but they are born without anywhere they can legally be without someone else's permission.
> Heads up, US Customs does not have to respect to GDPR.
Customs is part of a sovereign nation. What customs can and can't do has precious little bearing on what companies can and can't do. It's basically irrelevant.
> Neither does the walmart he shops at. Neither does Amazon if he orders something online.
Sure, if both are OK with not being able to operate in the EU _and_ believe the US government will take the political heat for refusing to enforce the EUs laws.
We also don't strictly _have_ to extradite criminals to other countries. But we usually do.
International law functions nothing like domestic law, because there is no higher power to say "no, you can't do that". If the EU can get the US to punish US companies through diplomacy, force or trades, then that's how things work. If they can't, then it's not how things work.
My guess is that the US won't shield them. It's not critical for US defense, largely redundant with data available from Facebook, and we're already fighting to keep our existing tech giants abroad. Clearview is more useful as a sacrificial pawn than trying to get it crowned a queen.
Yeah, I can't read it, but "millions" sound rather high to me. In 2019 there were 157 million American workers. That's expected to increase by 2 million in 2022, to 159 million workers. The number of workers is higher than it was, although perhaps that growth is lower than it would normally be, I don't know.
"Millions" does imply full percentage points of the workforce have long COVID. That sounds high to me, because it either means long COVID is pretty common or that a lot of people have gotten COVID.
It's entirely possible we're over-diagnosing it. The symptoms of long COVID overlap with practically every common condition out there, not to mention a lot of them can be stress induced. There's been a lot of stress going around, too.
I don't know if we'd expect to see an uptick in Social Security just yet. Unemployment was covering people up until fairly recently, and I believe is much easier to get.
More generally, I doubt the government will make it eligible for disability, or they'll limit it to extremely severe cases. I don't know that we can fiscally afford to not only lose whole digit percentages of the workforce, but to pay out benefits as well. I won't even pretend to be an economist, so I could be wrong, but it's not intuitive we can run the money printer like this in the face of declining productivity due to people dropping out of the workforce.
We're still not done yet, Omicron looks likely to infect a lot of people, including those who are vaccinated (and especially those who aren't boosted). If long COVID is as prevalent as the WSJ believes, letting people not work will be a big problem, and paying benefits will be unthinkable. If we're at millions of people now, we'll easily be at tens of millions by the time Omicron makes the rounds.
> Trimmers I met were earning $500 to $1,000 a day. $100 per lb trimmed was pretty common.
I don't believe this, the numbers don't line up. If it's wet, doing 5 pounds in a day is reasonable, but nobody's going to pay you $100/pound for it. 5 pounds of wet is a little over a pound dried, so $500 is around a quarter of the total sale price. I just don't believe anyone is paying that much for something a child with safety scissors could do (albeit much worse). I also don't believe that growers wouldn't simply buy automatic bud trimmers. They're not as good, but I would be willing to bet that consumers would be happy to not pay the apparent 25% trimmer markup in exchange for slightly less pretty buds.
If that's dry bud, the price is reasonable, but there's no way in hell anyone is trimming 5-10 pounds of dry bud a day. That's like a rolling curbside garbage bin full of weed.
I don't think they're using slave labor, but given the number of people I've heard wanting to do it so they can work with weed, I'd be surprised if they're paying significantly more than minimum wage. I'd wager it's very close to $15/hour + perks, where "perks" mostly means "all the free weed you can smoke".
The other poster is right, I can't see any way this is an accessibility issue.
You could try pushing back with a First Amendment complaint. Say you have a sincere and deeply held belief that using Facebook is wrong, and that forcing you to use it violates your First Amendment rights. The Supreme Court has held that beliefs do not need to be strictly religious in order to be protected. It's the same route anti-vaxxers take.
I still wouldn't hold my breath. You might win, but your children will already be in college by the time it's all sorted.
It's also not really safe to drink. Probably unlikely to kill you, but you're not going to get any assurances E. coli isn't in there.
It's pretty hard to mess up growing weed bad enough to hurt someone, unless you poison yourself with pesticides on accident (which aren't really necessary at least at the personal scale). If something bad happens, it's almost always to the plant.
I would think a prototype supersonic trebuchet would come with a lot more rules than a standard firearm.
They would be much closer to the safety precautions for a prototype firearm, which includes things like being behind a blast shield because there is no safe zone if it fails catastrophically.
I don't even trust that the sides of that thing are safe from shrapnel or the rubber bands whipping parts around. If one side of the machine gave way for some reason, it could absolutely swing sideways. That tiny string at the end is probably going fast enough to slice through skin and veins, and it's concerningly close to neck height.
He should have parked his car off to the side and used the engine block for cover. The paneling of the car will stop minor wood shrapnel, and the engine block should be able to stop any metal pieces that come off. Ballistic barriers would be better, but at least you're not standing there tempting fate with your squishy and easily separable limbs.
I'm a little doubtful. I think your standard pebble would vaporize from the friction with the air. A pebble certainly wouldn't survive re-entry into the atmosphere, so there's an upper bound on the speed before it disintegrates. If you made a vacuum between you and the wall, it might work?
One reason to use larger projectiles is to deliver similar amounts of energy without having to fight things like that.
Just to expand on that, patients aren't the only ones with a legitimate reason to access that data. Insurance companies need copies as well, so they would still want some kind of mass-data portal even if customers don't use it. If you change doctors, they want copies of your old medical records. If you see a specialist, if you go to the hospital, etc, etc. Pharmacies might call and ask if they think there's something weird about a prescription.
Direct patient contacts are a vanishingly small percentage of records requests for a doctor. Doctors could likely handle those via phone, but it doesn't solve the issue of needing an EMR.
Google owns the stuff you make during 20% time, iirc, so they use it as a feeder for new products.
Allegedly (I can't verify, but can't see why they'd lie) GMail, Google Maps and AdSense were all born out of people's 20% time and Google just swooped in and turned them into full on products.
It might be worth staying #3 in cloud if they could pull off products like that again. I can't help but notice that those products are all old, though.
In my short time working with it, I found it frustrating to debug. Using an incorrect tag meant it would simply be ignored with no indication of why my thing doesn't work, and I found tracing issues back to their HTML tag to be annoying.
The equivalent React/Vue/etc would throw a Javascript exception. Stacktraces aren't the best debugging experience, but they're functional.
I also think Angular inherits from a more traditional UI lineage of composing styling on an element, which I find less clear than something like React that has a more backend-y development flow. That's just personal preference, but I started on the backend so Angular's "build an element and then wire it up" makes less sense to me than React's "figure out the data flow and then build elements on that" style.
I don't find it showstopping. I wouldn't turn down a job because they use Angular. If someone asked me what framework to use, I just probably wouldn't suggest Angular.
An ESP32-CAM isn't far off. It's got a sticker sized footprint already. If you cut off the pins, the PCB is thicker than a sticker and the camera is a centimeter or two long, but they're like $10 a piece for ones with a camera and an SD slot.
I would tend to disagree because MicroPython is so abstracted that it resembles writing regular Python on a server more than it does anything embedded.
Just as an example, the WiFi setup resembles a server far more than an ESP32 with esp-idf. All you do is give it the connection details, and MicroPython seems to handle the details like trying to reconnect in the background. It's not far off from what systemd-networkd or similar provides. esp-idf forces you to handle that yourself, and to think about what you want to happen in that situation.
MicroPython also doesn't support threads afaict, so you don't even have to handle scheduling threads.
I like MicroPython as a way to run Raspberry Pi like stuff on the cheap, and it's a great learning tool in that sense, but you're still too far from the hardware to really be learning about embedded systems.
A desire implies a conscious and at least semi-reasonable actor.
People with desires behave rationally (mostly). If person X doesn't want to be homeless, they probably won't burn their house down. We can depend on that.
COVID is not a rational actor. It might burn its own house down and do a tapdance on the ashes.
Even though being less lethal is evolutionarily advantageous, COVID could absolutely become more lethal in the short term.
Right, but those aren't things an RCA is meant to address. The RCA identifies the specific method of failure. It's the starting point on your process improvement. X failed because Y, why did we allow Y to occur? The answers to those questions become deliverables.
An RCA doesn't handle those things because another section does. That way each team involved can look at what the issue was and how their team can prevent that. The authors solution eeks of a central committee that tells you how you could have prevented it, and they're often ineffective.
> It lets you build very resistant patterns: if your message-senders overwhelm your message receivers in HTTP you can end up with connection failures, get stuck waiting, etc.
I think the biggest drawback to HTTP in this space is that there's typically no coordination between clients and the server. Clients send requests when they want and the server has to respond immediately.
That becomes a big issue when you have an outage and all your clients are in retry loops, spiking your requests per second to 3x what they would normally be, on top of whatever the actual issue is.
Most of the retry stuff seems largely shared; i.e. your code should still have handlers for when Kafka isn't responding right. Kafka will only preserve messages on the queue, it won't help if you lose network connectivity, or your ACLs get messed up, or etc, etc.
> Regarding application patterns, ideally you're writing applications that read data from one topic (or receive messages, parse a file, etc) and write to another topic. Treating it as a request that will somehow be responded to later in time scares me and I wouldn't do it. What if your application needs to be restarted while some things are in-flight?
The pattern I've seen is to make the processing itself idempotent, and only ack messages once they've been successfully processed. So if you restart the app while it's processing, the message will sit there in Kafka as claimed until it hits the ack timeout, and then Kafka will give it to a new node.
As far as RPC, I'm not advocating that it's a good idea, but you could implement timeouts and retries on top of an event bus. Edge cases will abound, and I wouldn't want to be in charge of it, but you could shove that square block into the round hole if you push hard enough.
Why on Earth wouldn't you just make it a setting on the phone and expose that to apps? Have the apps read it on startup, and save it as part of the user profile server side. It basically becomes an email address.
> So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
They seem to do fine with email addresses. Again, I don't see why '[email protected]' (or an alternative with auth embedded) would be absurdly hard for developers. Someone will write a 'SendPushNotification' function that parses out the domain to send it to and the auth to use and send it, just like we've done with email since forever.
Google will likely know where you're sending your notifications, but they won't manage sending them (though they could probably scrape the contents since they own the OS).
> Most marginalized groups don't "overcompensate in achievement-related domains", and I don't see what mechanism would make LGBT people be any different.
A significant difference is that for the LGBT people, revealing their marginalized status is a choice. A Black kid can't pretend to be white, but a gay kid can pretend to be straight (or their birth gender). Adults can as well, but being able to get an education in the in group seems like a significant difference.
I doubt it's emotionally healthy to do so, but neither is getting discriminated against. Even having the option between a rock and a hard place might give people a sense of control over their lives that they lack if their only option is getting discriminated against.
Familial achievement might also be related. Many marginalized groups have highly heritable traits, like skin tone or facial features. Their families have been discriminated against for generations. Many LGBT people are born into non-marginalized families, so the median familial income might be higher. There might be data on this, but I couldn't find it easily, so I could be totally off base.
I'm not proposing that's the reasoning behind this effect, just pointing out there is a mechanism by which there would be a reasonable difference. Neither of those would account for the difference in college graduation rates for lesbians vs gay men, though.
I think it would be more effective to require sprinkler systems indoors on wooden homes. I'm seeing prices of $1-$2 per sqft, which is absolutely reasonable (although I anticipate prices are higher in LA, square footage is typically lower).
It's also probably drastically cheaper for everyone than more frequent inspections.
> The simplest way to counteract this bill would be to demand it require county inspection of all concrete homes after earthquakes
They would likely need to be inspected after wildfires as well. Concrete won't burn, but I believe prolonged exposure to high heat can weaken or crack it. That might go doubly so for something like a single-family home. There's a lot less concrete to absorb the heat, and the upper layers have nowhere to vent the heat. I wonder if it would crack at the foundation as the roof expands, but the floor doesn't because it can vent heat into the ground.
I've worked at some places that used Kafka (including LinkedIn), although I have never been responsible for running the platform itself. I'll chip in with what I see as the negatives.
Kafka sits at roughly the same tier as HTTP, but lacks a lot of the convention we have around HTTP. There's a lot of convention around HTTP that allows people to build generic tooling for any apps that use HTTP. Think visibility, metrics, logging, etc, etc. Those are all things you effectively get for free with HTTP in most languages. Afaict, most of that doesn't exist for Kafka in a terribly helpful. You can absolutely build something that will do distributed tracing for Kafka messages, but I'm not aware of a plug-and-play version like there are for most languages.
The fact that Kafka messages are effectively stateless (in the UDP sense, not the application sense) also trips up a lot of people. If you want to publish a message, and you care what happens to that message downstream, things get complicated. I've seen people do RPC over event buses where they actually want a response back, and it became this complicated system of creating new topics so the host that sent the request would get the response back. Again, in HTTP land, you'd just slap a loadbalancer in front of the app and be done. HTTP is stateful, and lends itself to stateful connections.
Another issues it that when you tell people that they can adjust their schema more often, they tend to go nuts. Schemas start changing left and right, and suddenly you now need a product to orchestrate these schema changes and ensuring you're using the right parser for the right message. Schema validation starts to become a significant hurdle.
It's also architecturally complicated to replace HTTP. An HTTP app can be just a single daemon, or a few daemons with a load balancer or two in front. Kafka is, at minimum, your app, a Kafka daemon, and a Zookeeper daemon (nb I'm not entirely sure Zookeeper is still required). You also have to deal with eventual consistency, which can make coding and reasoning about bugs dramatically harder than it needs to be. What happens when Kafka double-delivers a message?
My pitch is always that you shouldn't use Kafka unless it becomes architecturally simpler than the alternatives. There are problems to which Kafka is a better solution than HTTP, but they don't start with unstable schemas or databases being difficult. Huge volumes of data is a good reason to me, not being sure what your downstreams might be is an option. There are probably more, I'm not an expert.
> our customers don't understand the data they're shoving at us. But Kafka will take care of all of that for us
Kafka isn't going to help with this at all. If your HTTP app can't parse it, neither will your Kafka app. Kafka does have the ability to do replays, but so does shoving the requests in S3 or a databases for processing later. I promise you that "SELECT * FROM requests WHERE status='failed'" is drastically simpler than any Kafka alternative. It is neat that Kafka lets you "roll back time" like that, but you have to very carefully consider the prospect of re-processing the messages that already succeeded. It's very easy to get a bug where you have double entries in databases or other APIs because you're reprocessing a request.
I would like to see abolishment of speculative property ownership. You either use it, or it gets given to someone else.
You can't hold it and wait for the price to go up. You get a year, maybe two, and then it becomes public domain to anyone that will use it.
I find it absurd that people are born and indoctrinated to believe that because someone else says they own this bit of land that they've never used, no one else can use it.
People are literally born homeless. Their parents may have a home, and they may let their children use it, but they are born without anywhere they can legally be without someone else's permission.