Hardly reasonable. Domains are (in reality, if not in legislative fantasy) property of ICANN and merely rented by everyone else.
1,698 karma · joined January 24, 2011
I pirate everything.
Forced obsolescence, pervasive spyware/security problems, being locked into an "app" ecosystem, user-hostile antifeatures, lack of modifiability to deal with hardware degradation over time, etc.
This article also fails to mention Tizen. Has it been abandoned? It was absolutely terrible (millions upon millions of lines of the worst C code I've ever perused) but I thought it still existed, making vaguely similar claims to open-sourcehood as SailfishOS.
The real mobile OS to watch and advocate for is postmarketOS, which attempts to get mainline Linux kernels working on phones.
Ideally such a misdesigned API would not exist at all. Library interfaces should be engineered to prevent mistakes. Here are a handful of the problems I've run into recently when dealing with legacy OpenSSL code (legacy being the reason it uses OpenSSL, not the reason it was bad):
Some error codes are `int`s, other are `long`s. Different error codes need to be passed to different stringification functions, and these have different allocation and string-loading semantics. Why on earth do I have to manually load error strings in the first place? I don't pass a string-table handle into the stringification, so I don't even get context isolation (multiple instances of OpenSSL in one thread have conflicts)!
The entire BIO framework is insanely overcomplicated and could be stripped down to a minimal buffer-based encryption API (c.f. the BSD libtls API).
Then you have API like `SSL_CTX_set_verify` which simply ignores irrelevant flags rather than returning an error about them. This is terrible.
Nobody should use OpenSSL for new projects.
The lack of canonical names for parameters to data constructors is usually addressed by convention, and can present real problems for reading unfamiliar codebases. There are solutions, but this is a legitimate complaint and saying "OO also has some nameless things" doesn't help. A more helpful response would point at lenses and tools for jumping to datatype definitions, where fields' purposes should be documented.
Functional "mutation" tracking is subsumed by dataflow tracking, which is necessary in every programming language. The rebuttal is basically right here.
Partial application is occasionally useful, but in languages where it isn't built-in, it's easy to wrap multi-argument functions in closures to curry them by hand. The comparison to overloading is based on visual similarity but has no real relevance to potential difficulty in understanding the meaning of curried function calls.
The notes on higher-order function calls and state-passing are okay, but it would be nice to note the ways state-passing can be avoided even in pure code in many functional languages.
Lack of methods is a real annoyance, not because the syntax is important, but because methods enable type-dependent dispatch. The right response here is to point at typeclasses and traits, which are how ad-hoc polymorphism is usually done in functional programming languages. In Rust, for example, traits provide methods with the same syntax as "OO" classes.
Cons-/linked lists are O(n) access and there are many situations where avoiding significant slowdowns involves roundabout code transformations or "reverse; process; reverse" nonsense. Both random-access mutable containers and immutable functional ones are useful and there are applications where the constant slodown factor due to indirection (often more so than the logarithmic factor) associated with pure data structures is prohibitive.
Poo-pooing early return rather than pointing at tools in functional languages (do-notation) for writing similiarly expressive code is ignorant at best, and disingenuous at worst.
The problem of H-M error messages bringing up two parts of a program and saying they conflict, rather than pointing at one part of the program and saying it's a mistake, is a well-known drawback. There other points in the design space of type inference and typechecking that may better align with what programmers expect for assigning "blame" to type errors.
There are legitimate complaints about the annoyances of threading state through pure functions, but these have been made much more cogently by other sources within the "functional programming" community: Haskell has no end of blog posts about the utility of do-notation to provide the appearance of mutability while leaving state-manipulation implementable in pure, easily-unit-tested code, and early return can also be captured with monadic notation.
The naïve rejoinder to this approach is "why use a pure language if you're just going to emulate mutation?". The answer is that it lets you reuse the pure computations that transform state in other parts of your code without having to create dummy mutable objects for them to modify, and you have guarantees that unrelated state is not perturbed; this enables purely local reasoning which keeps code easy to understand.
Presumably this is to be considered worthwhile reading because the author has a job at Facebook. It's shameful that we implicitly support the cult of corporation-worship that assumes companies wielding great social power also confer supernatural programming skill or insight on their employees (by powers of selection or mere post-hoc association).
It would be easier to simply build a Qt version of the bits that depend on GTK, so Linux users can choose between those two. But considering how little Firefox seems to care about Linux user experience (FF has been broken with transparent GTK themes since forever and nobody cares; FF removed Linux native audio support and nobody cares), I doubt this will happen and I doubt a patch would be accepted upstream for reasons of "maintenance overhead". This ignores that maintenance overhead is much higher when two independent parties have to maintain the upstream and a patchset, but is for some reason accepted practice in the open-source world.
Why is HN voting so opaque, only explaining how votes work in scattered tidbits at the bottom of comment threads? A well-designed system doesn't work only because nobody knows how it works. The current method of "herd these sheeple through a maze they can't directly perceive" feels very patronizing.
At any rate, I'm not sure whether it's worth it to upvote the grandparent now, since it is apparently a censored viewpoint and merely shooting myself in the foot to do so.
No shit? Unless you mean that it's ignoring the "distributed systems" part of the cloud, which is mostly a shitshow. The provisioning/configuration-management stacks are all complete wrecks, stacking hacks atop ad-hoc container schemes atop a poorly-design OS. A real distributed OS would be so much simpler and more robust.
Calling it AI is very misleading when there has been minimal progress toward actual reasoning (the closest I've seen being some LSTM work on answering simple queries about scenarios based on prose descriptions of them). It's ML, as in "learning a function", not as in "general-purpose learning like an intelligent agent does".
There are specific reasons the Ouya and FxOS didn't make sense: an open game-console is already rather quixotic when all the games people want to play are closed-source and open non-games devices exist. FxOS was based on web technologies (huge mistake, given that they're garbage and inefficient), targetted at "emerging markets" (read: poor people, who for some reason are assumed to care less about their phones being slow and not having app compatibility?), and didn't make driver promises. If they had at least gotten calls to happen on a mainline kernel once I would have been convinced, but the real goal of FxOS was market share, not advancing user freedom (where hardware support, not userspace/apps, is the bottleneck). I don't know much about OpenSolaris.
The Librem 5 can be used in any of three ways:
- With a cellular carrier provided phone number, data plan, and WiFi
- With a cellular carrier data plan, and WiFi
- With no carrier, and using only WiFi
WiFi calling and VoIP calling will be able to be provided in WiFi or data plan modes. We expect to offer call-out, and call-in with phone numbers in all of these plans as well. If you still require a “traditional” phone number through a carrier and want to make unencrypted phone calls or messaging, it will be an option you can choose, but is not required (we recommend avoiding unencrypted phone calls).
The Librem 5 will have open-source drivers and a non-Android operating system running a mainline Linux kernel (atop which Android compatibility is trivial if folks want to run that).
Lots of HN readers have tech jobs and can afford to make history by crowdfunding: https://puri.sm/shop/librem-5/
The filesystem's "you can only persist uninterpreted bytes" policy means software can't maintain any kind of data invariant across runs; everything has to be revalidated if your process ends.
ACLs (e.g. unix permissions) are widely regarded as a mistake.
File locking is broken: https://gavv.github.io/blog/file-locks/
File metadata is easy to accidentally mangle (e.g. atime) and hurts performance (even "relatime" is slower than not causing a write for every read).
The filesystem is used both for users to organize their data files and for sharing of machine-interpreted data between programs (e.g. shared libraries and system configuration). Humans need human-readable names, and machines get confused by humans renaming things (and should probably be addressing by content, rather cryptographically or in terms of type signatures or specifications).
There are no asynchronous syscalls for interacting with the filesystem itself (e.g. `stat()`; for file contents things are onl slightly better).
Probably I'm still forgetting a number of problems, but these come to mind offhand.