The "blues" created the legislation & forced the workers to accept a shitty contract with no sick days. They could easily have refused to vote for it and let the strike happen w/o real sick days.
> They could easily have refused to vote for it and let the strike happen w/o real sick days.
No they could not. That would lead to economic catastrophe worse than march/april 2020. Dems would get swept next election and the workers wouldn't even win because dems would be forced to pass this exact law within a week of the strike starting. The government can't let 100,000 unrelated people lose their jobs, and they really can't let grocery stores run out of stuff or coal plants run out of coal causing blackouts.
Do they not have the option of forcing the railroads to give in on the sick leave issue? Did not "Team Blue" as in the Biden administration arrange this set of trade offs in the first place in the agreement which some of the most affected (screwed) workers are rejecting?
Team Blue had the complete authority to render the filibuster moot. We the people granted them more than enough power to do what we want done.
Fact is they hid behind the parliamentarian, insisted on bipartisan legislation as a priority and then proceeded to cede the power granted to make that excuse a reality today.
Personally, I reject it all and know damn well this could all play out differently and it doesn't because ordinary people are just not a priority.
Team Blue could in theory end the filibuster today if they dragged in the five MIA Senate Democrats who have not been voting on these measures and got Harris to break the tie.
As you say, they have their reasons for keeping it.
How convenient Team Pelosi split the issues into two bills. This result is to no credit of either party; as I've been commenting elsewhere, both hate this segment of the population.
it wouldn't have passed if it was just one bill. Republicans have no problem allowing a strike since democrats will take the blame for the economic fallout.
You know this how? And somehow the House couldn't have first tried a bill with both, then split them out?
Your claim would be more useful if you pointed out the vote was 52-43; with no great effort six Republicans voted for it, five Democrats are AWOL and Manchin for some reason I can't imagine voted against it.
The Senate also voted 26-69 against 60 more days of negotiations.
Umm, if everything was built around the idea that tweets were immutable, yeah I could imagine it's quite a bit of work to change things. Immutable and mutable data can be treated _very_ differently in systems bigger than the little toys you make for fun.
So... unless Grinnell does things very differently, the author did not learn Racket, they learned (Beginning/Intermediate/Advanced) Student Language, and that's the point.
Racket is a complicated language, designed primarily in order to support the easy creation of other languages: it would be as bad a choice (perhaps worse) for a first language as any other. All of the simplicity, focusing on learning to program, programming structurally based on data, that comes out of HtDP, is enabled by the restricted language.
It's too bad that this naming confusion persists, as I think it hurts the effort to focus on teaching _programming_ in intro classes, vs. teaching X language (I don't want to teach people Racket any more than I want to teach them Python or Java. They can learn those on their own -- they'll probably learn at least a half dozen other languages over their career, all on their own, if they stick with it). This curriculum is about figuring out how to most effectively teach people to program: the language was created, after the fact, to support that.
Fair point although I feel like Racket deserves credit for the way it builds upon itself. By design it allows you to have the Student Languages that are each iterations upon the previous, and all are valid Racket programs.
As a counter-example you can't do much of anything in Java without introducing class and public-static-void-main-string-args.
Sure, Racket has facilities to make implementing languages easier (that's the whole point), but that simply makes it _easier_ to implement BSL, etc. I could certainly, with more effort, implement BSL in Java or in any other language: the language that students are using really has nothing to do with the _host_ language. Things are somewhat confused by DrRacket (or, made simpler, depending on your perspective); the IDE is somewhat mixed up with everything else, but again, this functionality can and does exist in other editors: I could implement a mode for my BSL implemented in Java in, say, VS Code, with comparable features to DrRacket.
Or, to take a completely different tack, implement the IDE via the web a la WeScheme or, if you want an actual concrete example of something that isn't Racket hosted, Pyret.
What would be the point of implementing BSL in Java? You'd still have to teach the basics of object oriented programming and all the details of Java's implementation... unless you abstract all that away to the point were you aren't teaching Java anymore. BSL being easy to implement isn't as important as BSL being a useful subset of Racket that's easy for students to understand.
At least for me, the main reason for the remarkable to exist is reading scientific papers -- not having to print them out (and keep track of them) is a great benefit, but sometimes color is an important part of them. As a device for _writing_, I don't miss color at all, but for reading / annotating, it would make a big difference.
Reading PDFs on an e-reader is an awful experience though. Without reflowable text, either the device is physically larger than a page and cumbersome, or it's too small and zoomed out to read comfortably.
Ad-free doesn't necessarily mean they aren't tracking you, right? Viewership info is _still_ valuable, even if it's not being used right on the device.
Amazon's Smarthome stuff offers basically a bluetooth side-channel specifically for this purpose. It's called "Amazon Sidewalk", and they are already using it for Tile trackers, Ring Doorbell stuff (the doorbell even acts as a mesh point for this in some models)
Yep, eventually this technology will be worthwhile for folks with less scale to implement. Maybe Amazon will license access to Sidewalk. I believe Apple does a similar thing with their devices.
1. persistence, which obviously is hurt by them running out of money. Dropbox links apparently die eventually, static websites bitrot, etc. Things put on arxiv can be trusted enough to put links to them in papers, if needed.
2. Discoverability. Pre-print archives send out digests (usually people subscribe to particular areas). It's a low-effort way to distribute them. Related, by having things semi-centralized, it's easier to discover papers (they get indexed by google scholar, for example...).
Have you actually done any proofs in one of these systems? (or used one?)
Natural numbers are used because of the induction principle you get: it's very useful, and generally straightforward to use in lots of contexts (e.g., just the other day I had students proving the correctness of multiplication implemented as iterated addition; the multiplication is over integers, but the inner loop is after you've ensured what you are iterating is non-negative, since you decrement each iteration, and _proving_ it is much more straightforward if you interpret the loop counter as a natural number).
And your point about syntax is also baffling: Coq will display natural numbers as decimal literals, not "S(S(S...".
The fact that this was on your list of "improvements" rather than being a minimal requirement before being willing to launch, sell, etc, is pretty damning on it's own. No need to get misty-eyed.
Sorry, but that shows a fundamental misunderstanding of the problem space. We entered the "IP camera" market in 2010, when all the competitor products booted a 7-year old Linux kernel with busybox and UPnP'd a port to the public internet. Admin/admin, no string escaping, buffer overflows, inadvertently indexable by Google, rooted and/or turned into botnets.
Dropcam v1.0 eliminated all of those security problems.
The only gotcha is that we required cloud storage. However, my plan for v2.0 Dropcam was to go with open-source verified builds + kill the cloud-storage requirement (but offer it optionally with e2e crypto).
If I had required that at v1, the company wouldn't exist today, and worse stuff would have taken its place. Good product engineering requires prioritization and stepwise problem-solving, not ivory tower ethics.
> open-source verified builds [...], kill the cloud-storage requirement [...] optionally with e2e crypto
In your opinion, in the current space, do you think there's room for this kind of product now? I bet most of the readers here know why these are good features if you don't like adversarial software running sensors on your home network and uploading stuff, but I also bet we're in a tiny, tiny minority in the market.
1) You get no credit with customers for security features, only blame if they get hacked. You must invest in good security engineering because you believe it is a good thing and a good long term investment, it will only cost you in the short term.
2) Unfair competition from large tech and China-based companies, in terms of pricing and incumbent advantage. (And yes, I helped create this situation by selling Dropcam to Google, and profited from it)
In order to win, you'd have to make something better in every other respect (or find some yet-unknown killer feature that average customers actually care about), sell it for the same price, beat them in price wars, and spend enough on marketing to undo the PR damage they've done to the space AND rise above the noise floor.
Doesn't Apple's HomeKit do this the best? It was designed to be secure (so much that they had to backtrack on requiring hardware encryption chips) and it works locally.
With all respect, just because the state of the market was terrible doesn’t make a more secure insecure product good for the end user. And more than take market share away from less secure cameras, nest created a great ux helping expand use to unsophisticated consumers.
We'll have to let god balance that out on the scales of morality when I reach the pearly gates someday.
There's a lot of good and bad that came out of Dropcam but I think it's been mostly good. Lives saved, murderers in jail, happy moments captured that would otherwise have been lost.
Plus, we had every intention of improving this aspect, and I'm even commenting unpaid on the internet to put as much pressure as I can on Google to follow through on that!
nest created a great ux helping expand use to unsophisticated consumers
Thanks for the compliment though. Maybe god will pardon those who create good UX. :)
> With all respect, just because the state of the market was terrible doesn’t make a more secure insecure product good for the end user.
With all respect, let us know when you (or anyone else) releases a perfect version of a product. Nobody has unlimited money and time in which to polish a product to perfection.
I'm in the throes of this right now, trying to beat a once-miserable codebase into something that that improves our customers' lives, is stable, is secure, etc. on a shoestring budget. It's a hard, wretched slog but we're doing it, one point release at a time.
This is exactly right, and way better than my reply.
Your polish can improve as you scale and get more resources. That doesn't mean there isn't a min-bar of basic security practices and ethics, but if min-bar is perfection on all counts, get ready for a long and fruitless existence...!
Nobody's asking for perfection, just something that doesn't get hacked and play pornography for 3 year olds. Nest had polish. Security took a backseat to UX, and here we are.
It's silly to call that a minimal requirement. There's nothing simple about local pairing especially when you need to be concerned about your entire market, what phones they're using, what devices they're using, and how much funding your call center has. Yours seems like a very naive, hindsight is 20/20, comment.
take your holier than thou attitude out the door. it's so easy to play an arm chair quarter back and not know the struggles people in the tranches have to go through to get features and improvements through management.
I mean, if you design an esolang for the competition task and implement an optimizing compiler that's faster than any general purpose language out there, that absolutely feels like something that should be rewarded by the spirit of the competition! So it's okay that it's allowed by the letter of the competition, too.
