Of course they do want the independence, why would they not. It's just that after decades of occupation and China's economic rise, they feel that that is an impossible goal, at least until China implodes like the USSR did - which may or may not ever happen.
So, they are asking for the next best option as a compromise - even the proposal is called middle-way for it is a compromise.
There are benefits to being associated with a global superpower in regards to quality of life improvements. Obviously they are not worth the cultural and human costs that Tibet is currently experiencing, but if we can get true autonomy, I don't see why you wouldn't want both. I say that as a Tibetan in exile.
There are some Tibetans that don't think true autonomy is possible with the CCP and thus still want independence though.
We have 4 people, with the students Quishu Wu and Aditya Pakki intruducing the faulty patches, and the 2 others, Prof Kangjie Lu and Ass.Prof Wengwen Wang patching vulnerabilities in the same area. Banning the leader seems ok to me, even if he produced some good fixes and SW to detect it. The only question is Wang who is now in Georgia, and was never caught. Maybe he left Lu at umn because of his questionable ethics.
The problem he is referring to is not that facebook narrows down the audience based off of likes. His problem is that his mom, and consequently other family members, always immediately likes his posts regardless of the content which narrows the audience down to his family members instead of the intended audience. He wants Facebook to take into account that the person liking his post is his mom before narrowing down the audience to family members.
The post is intended for an audience including his mom (she interacts with his posts by liking them). The author's argument is that Facebook's algorithm is (incorrectly) assuming that her interaction is based on interest in the actual content, rather than her association with the author.
Sure it is. He even says that he later changes the settings to his mom sees it. He wants his mom to see it, he just doesn't want Facebook to get the wrong interpretation by his mom liking it.
Let's see... they developed a way to hide a bomb powerful enough to bring down an airliner inside a laptop, but not a way to buy tickets for flights other than a few specific routes on a few specific airlines? If you believe that, I've got a bridge to sell you.
I know some (maybe even most) of the affected airlines have significant government ownership. It could therefore be a way of gaining political leverage.
It could also be a leg-up to American carriers competing on those routes. Another commercial option is a tactic to require implementation of security practices that involve American-made equipment.
I'm sure there are many other possibilities that make more sense than the public explanation, which only seems to make sense if we assume the people protecting us are incredibly stupid. I don't think they are, so the public story is probably just a cover.
I guess what I'm really asking (given the original subject of the post being declining Mac sales) is who is going to buy it? You can buy a Chromebook with a 13" IPS touchscreen that looks better than the Air for $250. The air is a decent machine for doing dev work, but compared to what its competitors it is a complete rip-off. Its only selling point is running OS X.
I mean, that's the strongest decision when evaluating a new machine for me. If someone wants to replace my machine, they also need to replace the software on the machine, and I don't think the Chromebook is even aimed in the same direction as Mac OS X. It doesn't have the breadth of software, hardware, or even file interaction necessary to get through the classes I took in college, let alone my self education.
If you know exactly what you need from your machine, the chromebook may very well be sufficient. I don't think you can depend on it as a general purpose computer quite yet.
Well what do most people (not just devs) like about macbooks? I would say build quality, "it just works" (macOS), and status as an apple product. The entry level macbook air still has those things. As for the chromebook comparison, macbooks have always been more expensive than its competitors at the same spec level, so this is nothing new.
I feel like saying it isn't a viable machine because of old specs isn't necessarily true since people will still buy it.
I believe, the distinction that orclev mentioned was that in Rust, you specifically have to be aware when something is allocated to the stack or heap, but in Go, you don't have to since the compiler deals with it. Obviously Go allocates to both stack and heap, it's just that the user doesn't need to know which.
Fair enough. I simply meant that Go's semantics let you reason about what lives on the stack vs what lives on the heap much like you can in Rust (though in Rust it's clearer still because there is no escape analysis at all). While you don't need to know from a correctness perspective, you can reliably reason about what will live on the stack vs heap in a way you can't in, say, Java.
No, you can't really reason properly about what lives on the stack. As the Go FAQ say, you can safely assume a variable will be allocated on the stack if you never take a reference of it, but that's not always clear as it seems. For instance, if you call a method on your variable, you can't immediately know by looking at the method whether the receiver is by-reference (pointer receiver) or by value. If you're using a pointer receiver, the variable's address may be taken, so the compiler has to perform escape analysis.
Once you take the address and escape analysis is performed, you've got no way to easily reason about what's on the stack vs. what's on the heap, without delving into the gory implementation details which may be changed in future versions.
Since Go isn't C++ and doesn't have a huge and complicated standard that guarantees compiler optimizations, you can't really reason about what's going on.
This is essentially the same situation as Java, although the Hotspot JVM's escape analysis is probably less 'basic'.
