822 karma · joined August 15, 2019
My paranoid 4 glasses of wine self can believe nothing other than money being involved.
What is with all the Zoom hate? The company have been around for a decade, enjoyed relatively mediocre success until the outbreak of Covid, and suddenly apparently since they're experiencing huge demand and press coverage, every man and his dog is finding reasons to write a blog post complaining about them.
I've read some article splitting hairs over the nuances of "end to end encryption" and how Zoom is so horrible, evil and wrong because they, like almost every telecommunication provider under the sun, can intercept your calls. What makes Zoom so special?
What's driving all this hate? Because it's a far more interesting question than what technical flaws Zoom, or any other product in this category, almost certainly suffer from.
Has someone done any security analysis of Houseparty? It's experienced surge growth in the same period. But in the time I've seen maybe 20 Zoom-hate articles on HN I haven't seen a single mention of Houseparty. What about Google Hangouts: is it "end"-to-"end" "encrypted"? What about its recording feature? Where are the articles? Where is all the hate?
Why?
You're welcome to absorb all the externalized costs your heart desires, but in future please consider reviewing HN's rules before bandying attacks like "smug" and "superior".
There is a fabulously unending depth to explore in the chasm lying between these opposing world views. It would be more than possible to write a book on the topic and fail to cover it all, however here are some of the most important aspects, from my perspective at least:
* given a perfectly functional tool relied on heavily by its user to perform their job, and given that tool suddenly decides to change shape such that it no longer fits the user's hand without retraining, nor fits with the remainder of the user's toolset, including custom tools the user has invested in producing, the continued utility of the no-longer-functioning tool is called into question, along with a deserved reappraisal of the tool's applicability in the context of the user's original intended problem domain.
* when the reason for its reshaping is to solve what are highly important problems from the perspective of the tool, but much less so from the perspective of the average user, and that user's application of the tool to real world problems, it can no longer be said that the tool is simply an implement that may be called and relied upon at any point in future -- the tool develops a chaotic life and importance all of its own, and may choose to reshape once again at any future moment (and indeed in this case it has). It is no longer a tool, but some sentient entity demanding unpredictable ongoing costs and attention paid all of its own.
* given a tool that promises to cease functioning 'correctly' at any future moment based on its own whim, preferences, industry fashions and styles, in an ecosystem where many similar such tools exist that explicitly promise not to cease functioning over the same time period, it is a fool's errand to pick the tool that promises to externalize additional costs on the user when alternatives exist that avoid any such cost.
* given tool designers who externalize almost frivolously minor technical costs on to every user, where each 'minor' change is amplified perhaps 10000 times over and directly translates into expensive engineering time, the question is easily raised whether the philosophy of the tool is appropriate for its advertised utility, and whether continued reliance on the tool makes business sense. In economic terms, what was the cost to productivity of the retraining and re-tooling of users compared to any alleged future productivity improvement?
* had I written these scripts in bash, C# or C++, they would not have broken even remotely to the same degree. Of course these are not some completely unevolving entities either, however all take the promise of forwards compatibility deadly seriously, and it is more than possible to find 10-20 year old programs written in C++ or bash that continue functioning to the present day. From my perspective, they are therefore excellent and highly dependable tools.
Utterly pointless and reputationally ruinous. I don't do serious work in Python any more
Dealer goes bust, market takes a huge hit, and the collateral value shrinks in correspondence to that hit. Madness. And still the markets have barely even sniffed at these announcements.
I expect before this is all over, POTUS will be making those daily coronavirus livestreams wearing fancy dress and cracking jokes just to keep people interested, because they've already spent every last drop of substance in the opening weeks of what promises to be a 6+ month journey.
Expecting another rally followed by another crash
Such an impressive single day drop, it's almost like they stopped testing people..
Meanwhile, I recommend relying on vastly more credible and less easily falsified sources to judge how China is recovering.
If you trust your eyes, https://www.youtube.com/watch?v=Tf-4zQADLS8
If you trust TomTom, https://www.tomtom.com/en_gb/traffic-index/wuhan-traffic
FWIW, prior to the recent change, I believe the situation had been the status quo since well into the 90s. I only started contracting circa 2007
People had exactly the same experiences with Mesos and OpenStack, but k8s has decent tooling for turning up many clusters, so there is an easy workaround
- the "vendor's" right to substitute himself for a replacement they subcontract (via employment or otherwise) to, irrespective of the client's deemed suitability of the chosen replacement
- the "vendor's" right to a significant level of autonomy, such as the ability to choose their working hours and lunches, and have high level control over their workflow
- the process of determination 'employee' vs 'vendor' must be significantly documented and can be challenged in retrospect for years after completion of the contract
Falling on the wrong side of a determination could leave the client liable for mandatory national insurance and pay-as-you-earn tax deductions. Now HMRC need not prosecute individual contractors, but instead clients (who may hire hundreds of contractors), making the enforcement process much more efficient for them, and much higher risk for the clients.
Net result for companies: building big overnight temporary teams out of contractors e.g. for 6-12 month projects are vastly less likely to do so, for fear that at some future date, the tax man could claw back a year's worth of tax for e.g. 20 contractors on the same project, with non-compliance and late payment penalties lumped on top (which themselves increase with respect to how long it took HMRC to get around to investigating you). It could be the case (hypothetically) that it would only require one member of a team to report the inability to substitute, or the presence of a line manager, for an entire project team's worth of tax to get a question mark placed next to it.
Net result for contractors: anyone who understands what's going on has either pivoted into becoming a permanent employee, avoiding the whole mess, since contracting is an expensive activity to begin with, and the premium has now been removed, or has banded with a few friends and attempted to set up "micro agencies". I've already encountered these, where substitution was advertised very early in conversation.
Net result for the market: it will be all but gone by April 2020.
The level of censorship around unquestionably authentic videos coming out of China has left me in a deep state of shock
I assume at least one, the person who thought the last redesign was a good idea.
in home settings this step has been automated for something like a decade or more. One of UPnP or NAT-PMP are available on basically every router
I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space
Pretty sure Reader had that effect on a large chunk of the technical base they previously relied heavily on.
Is there any possibility e.g. of an FD reuse issue in the code somewhere? It might even be possible to spot it with strace (although you need to start the container with the right caps to try that). An example where this can happen is programs closing 'stderr' fd 2, only for e.g. SQLite to open its database reusing fd 2, then some library code calls fprintf(stderr, ..) etc.
Would love a copy of the DB 'sometime before' and after to look at. There are tools around for inspecting SQLite databases on a page-by-page basis
The only thing I use Chrome for is gaming, graphics perf is still miles better than Firefox. But I'd never trust Chrome with anything as much as a private URL or a username or password, for much the same reason I wouldn't stick my hand through the bars of a cage while visiting the zoo. Did they ever get around to fixing that opt-out password sync crap?
- expand to consume every new use case and buzzword that comes along. Survive in some form indefinitely, while the product becomes less concrete and meaningful over time. The product continues to succeed not because it is technically best in class any more, but sheer momentum of the large base of existing users it serves adequately
- remain focused to the original mission, delivering iterative improvements over time. Watch waves of loyal users get eaten away one after another by the tide of the current technological buzz
VB was mostly the second case, although it did have many cousins in the form of VBA and ASP. The original tool - VB itself, was only ever relevant to desktop computing. By the time it got merged into Visual Studio, I believe the RAD aspect of the tool had already mostly disappeared (although VS even today still offers some variety of the original experience!)
VB in its prime was a beautiful thing, and the experience AFAIK remains unmatched to this very day. I've pined for a "client/server VB" on many occasions.
On the intermixing of source and header files, it doesn't quite work the way you mentioned. It's not possible to just cut-paste any old public object definition into a header file without at least applying 'static' to it, and that only works where the object truly is private to each translation unit. It's not so easy e.g. to instantiate a global variable shared across the whole program this way, so 'header only' also implies 'almost certainly free of globals', which is a good sign of hygiene
edit: yikes, in this case, the implication is totally invalid