curryst

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 'username@notification.provider.com' (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.

it seems quite obvious to me that in the vast majority of cases, the considerably simpler* model of (green) threads means you're making the exact same trade-off: Simpler to write and debug code at the cost of needing more memory when running the app you write.

I don't find it's quite that simple.

My experience is that the complexity of CPS tends to scale linearly with use, whereas threads scale exponentially. For small uses threads are easier, but CPS quickly catches up.

CPS forces you to actually declare a dependency tree for your data. Things depend on other things, and that exists in your code. It's very easy for threads to end up a mess, where it's not clear how data is passing through the code, which causes bugs like deadlocks and race conditions.

It's deceptively easy to write code where thread A tries to lock mutexes X and Y, and thread C tries to lock mutexes Y and X, and it deadlocks because neither thread can get both locks.

It would be much harder and more arcane to do that in Javascript or in Python's async. I'm not saying it's impossible, but I don't think I've ever accidentally created a race condition or deadlock in their CPS engines.

TL;DR if your functions are only marked async so you can await something, threading probably is simpler. If you're actually passing promises around, things become much more favorable to CPS.

A lot of it will be pushed down the stack into infrastructure. Infrastructure typically tails software, so over the next decade I would expect to see shifts in the infrastructure to accommodate this.

For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token (or whatever) to the database, which runs the query and filters out results you personally can't access, and then nocode app formats it (basically, in a naive implementation).

IT gets to maintain control of the ACLs, and permissions become seamlessly uniform across applications. Marketing doesn't have to talk to IT get to credentials for the database and talk about security, they just set up a new app and the database makes sure that users are allowed to access that data.

That will also cause a cottage industry of tools for managing those permissions to spring up.

I would keep a serious eye on Microsoft in this space. Active Directory + SQL Server gives them serious inroads into major companies for something like this. Sharepoint is also already in the same vein. If they bought out a nocode platform, replaced Sharepoint with it and integrated the ACLs for AD and SQL Server, they could have a really compelling product in this space. It would be a perfect add-on product for Office 365, and the billing is already set up for a lot of companies.

I don't think this is strictly true. There are 2 underlying factors:

1. Public companies have tons of disclosure requirements, which makes it far more likely that someone notices their misconduct. That's a really heavy bias in the data.

2. Private companies are typically smaller, so the range of ways to abuse customers is smaller. Nestle can buy out the water rights for entire regions; the median private company probably couldn't buy enough water to mess up a city.

Given unlimited potential, no, it's not. Given our current constraints in terms of energy density and electronics size, yes, it probably is.

In an unlimited potential world, it would be great to have a phone that was like an A0 sheet of paper folded into an A7 or A8 sheet. So you could "unfold" your phone several times to get a display ranging from a standard cell phone up to a meter across display. No more conference room TVs, someone will just unfold their phone and hang it up.

In a far more advanced world, I expect some kind of human-machine interface will crop up. The twist I expect is that I think they'll be genetically engineered, a la CRISPR. Rather than cutting people open and putting metal inside, they'll inject you with a virus or something that leverages your body's existing systems to make your body build that feature itself.

I.e. if you want that human - computer interlink, they give you a virus that causes your body to deposit iron inside your ears in the shape of an antenna and causes the growth of new nerve tissue to convert those into nerve signals to the brain and maybe a new part of the brain that can "decode" the new nerve signals.

I think some entire themes just don't translate well. Explosions lose a lot of oomph if they aren't backed by powerful subwoofers. It's hard to pass environmental detail on an iPhone. Things like the scene with the bioluminescent creatures in Life of Pi lose a lot when you're on a small form factor screen. They also lose a lot if you have any glare on the screen.

adjust your aesthetic to create a great experience on everything from a silver screen to an iPhone and let us give you our money without denigrating us for not placing our butts in theater seats.

This seems like the equivalent of saying "just write a single app that looks native everywhere". You're not going to get a bespoke C++ app back, you're going to get an Electron app that doesn't make anyone excited, but is easy to write.

Movies are the same. If you're designing for the lowest common denominator, you don't get a movie that looks great everywhere. You get a movie that looks great on an iPhone, and it's pointless to watch anywhere else because it's going to look the same. I don't see how you can make a single movie that both utilizes the high-end equipment in a theater to it's fullest, but also doesn't lose anything when you watch it on an iPhone using the built-in speakers.

They could do some "remastering" to release different versions for different platforms, but film buffs are always going to hold that some format is the "superior" one.

Does anyone have a link to any of the court documents? I'm curious what their legal basis for this is, and I can't find any actual legalese.

Amazon being liable doesn't sound likely to me, but perhaps they've actually found a way to do it.

Probably not a literal get out of jail free card, but it gives you a lot of options to impede the investigation.

From what I can tell, investigations are comprised of a large network of loosely connected groups that need to coordinate to win.

The game is to use it to interrupt communications between loosely affiliated parties in the investigation. You're not going to convince the director of the FBI to drop it, but you probably could wreak havoc on the investigation by sending emails allegedly from the FBI to the labs, local law enforcement, etc. Don't tell them to drop it, just redirect them to something less useful. "Oh, we don't need those reports right now, prioritize analyzing <something you know isn't helpful>". Try to get local PD to go knocking on doors or something that won't help, but isn't too obviously unhelpful.

You could also try to make the various groups mad at each other to reduce cohesion.

It's probably not going to keep you out of jail, but it buys you some time.

We don't have to argue about it, you can look at the Wisconsin law for it.

“Dangerous weapon" means any firearm, whether loaded or unloaded; any device designed as a weapon and capable of producing death or great bodily harm; any ligature or other instrumentality used on the throat, neck, nose, or mouth of another person to impede, partially or completely, breathing or circulation of blood; any electric weapon, as defined in s. 941.295 (1c) (a); or any other device or instrumentality which, in the manner it is used or intended to be used, is calculated or likely to produce death or great bodily harm.

I would say a skateboard, wielded as a weapon, is likely to produce death or great bodily harm. Getting hit in the head with a skateboard even once seems likely to cause a concussion or maybe even internal bleeding.

You probably do have a good number of items that could be classified as deadly weapons on your desk, depending on how they were used.

To answer your lower question since I can't respond directly, the legal difference between a rifle and pistol is pretty much only barrel length.

This is only half-true. The difference between a pistol and a rifle is whether it has a stock. The difference between a normal rifle and a short-barreled rifle is whether the barrel is 16" or not.

I'm not saying it makes more sense, but that is the classification the ATF uses. Never put a stock on any weapon with less than a 16" barrel, unless you're really, really, really sure you fall under some kind of exemption (i.e. that might not apply to black powder weapons).

I do wish prices would come down, but even at equivalent pricing, I think it's a net win. I think a lot of people have forgotten how god awful cable was.

* I can watch what I want whenever. No more sitting down because I have a half hour to kill and there's nothing better than Pet Police on.

* No more screwing with DVR settings if you want to watch something while you're gone.

* No more dealing with needing to watch things before they get purged from your DVR.

* No more dealing with someone else in your house deleting your show off the DVR.

* No more dealing with wanting to watch your show in the bedroom, but you recorded it on the DVR in the living room.

* No more ads (largely).

* If your wages are keeping up with inflation, static pricing is actually a decrease in cost over time. Cable was $100/month like a decade ago; $100 is less money today. Similar situation to video games.

I would have to flip through a lot of apps before the apps were more annoying than trying to configure the DVR through a remote with no keyboard that only reads my keypresses a third of the time.

Cable sucks. Streaming is better. I do think piracy is more convenient than streaming in the current layout, though.

No wonder piracy is in a resurgence.

The media portrayal of this has been bad. That reporting is based on a report that showed Bittorrent is the #1 source of traffic in EMEA and APAC, and #2 in the Americas in 2018.

The first problem is granularity. The US is only about a third the population of the Americas, and Sandvine never published more granular data that I can see (presumably they charge for that?). Any effect on the US is going to be muddled by effects in other countries.

The second is that they're measuring it as a % of total internet traffic. That makes sense for the segment they seem to be in (advising ISPs and the like), but it's hard to translate that into the amount of stuff people are pirating. File sizes are variable; 4k content making it's way into pirating might have an effect. VPNs and seedboxes will also cause traffic to be misattributed. It's entirely possible that the amount of stuff people pirate in the US never changed, it just started to be tunneled to Europe when ISPs got stricter.

Fourth, they're equating Bittorrent traffic and piracy. The common use of the Bittorrent client is undeniably piracy, but P2P apps have become more common (for video streaming and game update distribution for example) and I'm curious whether they actually differentiate between the two. Again, the target market for this report is interested in how to handle the traffic, not whether it's illegal. There would be no reason for the author of the report to bother with that.

As an inverse of the above, it does not count piracy via sites like Mega, or watching/downloading movies on YouTube, etc.

Lastly, the media reporting completely ignored that internet access is still spreading in developing nations. Due to the granularity, it's impossible to say if people in the US are pirating more, or if more people in South America have gotten internet access and are torrenting stuff.