I am guessing, for the same reason I can have a picknick in the local park with a few friends and discuss intimate matters. This takes place in public because that is convenient, but I still don't appreciate random passers-by interjecting their opinion. It's fine to listen in though, if you're sitting close by. Most people intuitively understand this.
Online, this intuition sometimes disappears, and people feel that the fact that something is readable to them, implies it is meant for them to interact with.
a better example is a meetup in a closed room. (i just attended one of those). you are clearly part of the group, but you get to overhear private conversations, and sometimes it is appropriate to join in, and sometimes it isn't. the difference is that when i walk around the room from group to group, i get signals if i am welcome to join or i am being ignored. these signals are missing online.
But does the comparison really hold? IMO, you'd have to have your "intimate" public discussion carved in stone or something to be comparable. Your example is more like SnapChat or any other platform that limits the lifetime of postings.
It wasn't like that when I visited a few years ago. We just booked a hotel, got on a plane and went there. I can't find this requirement on their COVID page either. Do you have a link?
For entry measures, countries of entry are divided into 3 categories (blue, yellow and red). The entry modalities and visa regulations are then based on the colours.
Blue = Tourism allowed with visa
Yellow/ Red = Tourism not allowed
The categories are reviewed at regular intervals and countries can be reassigned to a different category in the event of a new review, which means that relaxations can be withdrawn again if necessary.
Germany is currently Category Blue.
NOTE!
Visas can only be applied for if a travel agency/travel company based in Japan acts as guarantor and registers with the Japanese Ministry of Health (see below).
At the moment, an application is only possible for package/group tours organized by a travel agency based in Japan as well as with continuous group guidance on site without individually plannable days as well as only with a locally resident tour guide. Individual tourism is not possible.
You are advocating willful destruction of property. Property that is neither yours nor FTDI's. This is illegal, and broadly considered bad taste.
A counterfeiter commiting crimes against FTDI does not excuse FTDI committing crimes against a third party (i.e. the consumer).
The world being safer without the counterfeit products also does not excuse the FTDI destroying things that aren't theirs.
The justice system being ineffective at addressing counterfeiters is also no excuse for FTDI to take matters into their own hands. Vigilante justice is usually illegal.
Programmers make mistakes. A bug in your counterfeit detection code may end up destroying legit products. In addition, you can not be sure destroying a product will be safe - if the chip is in a medical device, you might be killing someone. The entire idea of destroying a product without explicitly being told to do so is fraught with peril.
You deal in false binaries. The third, imo correct, option is for FTDI to design software that works correctly with their own product, and spend no effort on the counterfeits - neither to get them to work correctly, nor to brick them on purpose.
A fourth option, if you want to spend some effort on something other than destruction of property, is to take option three, and also alert the user that they are using a counterfeit chip with unpredictable behaviour, and in your airplane example, advise the user they should probably not take off. If you want to be pro-consumer, this is a better way to go about it than smashing their stuff.
From the consumer's perspective, they had a working device, and a firmware update bricked it on purpose. It is possibly out of warranty, in which case they end up footing the bill (or experiencing frustration) for replacement and downtime. It takes Olympic levels of mental gymnastics to view that as 'pro-consumer', imo.
The OS vendor could "destroy" you by making changes to the OS that affect your app, right? The Old New Thing[0] is full of stories of apps that exploited undocumented implementation details of the OS, and were surprised that those aspects were in fact changed in a later OS version.
To its credit (though not everyone agrees), MS has spent a lot of effort making compatibility shims, basically doing other people's work for them, but they have no such obligation.
This strikes me as a different class of problem. Of course software developers are at the mercy of other software and hardware, and have been since the days of yore. And even in that case, you could still potentially debug the issue.
This is a different class of problem. In this case, a gatekeeper is asking you to use their service to distribute software through their channel, and that channel is governed by vague rules that may, in fact, be enforced on a whim. Further, the gatekeeper isn't being clear with the rules, and why you may have run afoul of them.
That's a software problem for any language. Will the authors break compatibility? They sure can and do all the time. You are always at someone else's mercy in computer science.
> Please just let me opt out of this cookie consent idiocy.
This addon [1] will let you do just that. You can configure it to tell all sites to slurp as much of your data as they want, if that's what you prefer.
> How are we making anything better with all these cookie consent pop ups?
"We" are giving people back control over what happens with information about them. This is widely considered a good idea, though perhaps not near you ;) The pop-up part can be automated by software if you prefer a one-size-fits-all configuration, as described above.
> Add-ons like those should scare you because they give a small third party free access to every web site you visit.
I think that they should scare you because they're, not surreptitiously but by design, consenting to innumerable requests to share your data without your interaction; but I guess to each their own scariness.
I am quite turned off by the following passage near the top of this page:
> bits of configs can't be reused. For example, while YAML, in theory, supports reusing/including bits of the config (they call it anchors), some software like Github Actions doesn't support it.
I use YAML configuration for Home Assistant all the time, and the includes work just fine. This article is off to a really weak start by saying "config files can not have X, because well they can just fine but arbitrary software Y doesn't support it". Especially damning because the proposed solution is to embed a whole other programming language within your program! If you can change the code of the consuming program, then just add support for imports, instead of adding a Python dependency.
The #[non_exhaustive] feature makes me unreasonably happy. It is a problem I hadn't even realized might occur, and the solution is very elegant, forcing depending code to be sufficiently general.
For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally. Matching on _Nonexhaustive as a user of the library is of course a bad idea. There've been proposals to a lint like
#[deny(reachable)] to make such checks possible for #[non_exhaustive] as well but it seems that nothing has happened yet: https://github.com/rust-lang/rust/issues/44109#issuecomment-...
> For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally.
I don't think this is necessary. The attribute in question is applied to an enum variant, and that variant's constructor is then given only crate-wide visibility. This looks to be simply a compiler-enforced codification of the pattern you're describing.
It can both be applied to enum variants as well as to entire enums. I meant the latter case. From the release announcement:
> A perhaps more important aspect of #[non_exhaustive] is that it can also be attached to enums themselves. An example, taken from the standard library, is Ordering
A little bit further down, I'm matching on the enum in the to_oid function. I'd prefer if I got an error or at least a warning pointing to the match if I added a new enum case and didn't update the match statement.
non_exhaustive only affects downstream code, within the crate you can still treat it exhaustively. For example in this playground[0] if you build in test mode the match works inside the crate, but fails in the doc-test because that is treated as external code.
From a non-US perspective, I find it highly surprising that having children and wanting to care for them is framed as a deviant "personal choice" rather than something most humans do that is very normal and expected.
Do you honestly think making people choose between raising children and having gainful employment is normal and acceptable?
To answer your question, yes, being a parent is a normal part of life and society should be accomodating to the needs of parents, to the extent that is possible. (In fact, I struggle to see why working somewhere else than your designated office for a few hours a week would be a 'privilege' if the particulars of the job allow for it. I get the impression that bosses that disallow this are on a power trip and do not have the best interests of their workers, and thus their company, in mind.)
> Do you honestly think making people choose between raising children and having gainful employment is normal and acceptable?
The argument I was making is that they are expecting privileges for being a parent. I know a number of women who see their career as more important than having children as plenty of others who see their children as more important than a career. Life is full of compromises, why should having children be seen otherwise.
The world is overpopulated and we should be looking for ways to bring the population down humanely before nature does it in a far harsher manner.
I really don't get the time picker design that basically works as two long comboboxes side by side. Especially the minute picker requires far too much scrolling/swiping for what it's worth.
I much prefer the Android dialog, with a clock face that allows me to select the right time with two clicks [1]. Am I alone in this, and is it hated by all and thus ignored in other OSes? Is it patented and thus unavailable for anyone but Google? I don't get it.
It doesn't have two rings anymore, you choose the hours and then it changes the ring to minutes for you to choose that. Functionally the same I would say, for all but the most pedantic person.
And I believe it has been that way for several years...I don't recall ever seeing hours and minutes rings visible at the same time.
Well, no, that is still the current time picker. I find it the fastest and easiest way if picking a time on a touchscreen. Not sure if it would work as well with a mouse, though. And it takes a lot of space.
Online, this intuition sometimes disappears, and people feel that the fact that something is readable to them, implies it is meant for them to interact with.