HN user
Not really. Tizen wouldn't work on a small low-power and low-RAM bluetooth SoC like the NRF52 this watch has. Tizen requires iirc a minimum of 512MB or 256 MB for "Tizen light". So: different focus, much bigger SoC and RAM, much shorter battery time.
I do that too. For the latter, I use the redirector addon https://addons.mozilla.org/de/firefox/addon/redirector/
Actually, packs of 10 eggs are more common in continental Europe (e.g. Germany, France) than packs of 12 eggs these days.
the librem isn't more open than the PinePhone at all. The only difference is that they put the modem on a separate card… but that doesn't make it any more open at all. What matters, given the fact that there just isn't any open modem out there, is the fact that the modem is kept isolated from the SoC in a way that doesn't allow the modem to access anything the SoC doesn't explicitly give it.
The only problem remaining, on this particular device, is direct connection of physical sensors (microphone, GPS, etc) directly to the modem
is that even the case of the microphone? My understanding was that - independently of the possibility to turn the microphone and modem off with kill switches - all audio data to the modem comes via I2S from the SoC anyways, i.e. that the microphone is NOT directly connected to the modem but to the SoC (possibly via a separate audio codec Chip) and that the SoC serves the modem via I2S whatever audio data the user pleases (whether that be from the microphone or whatever else).
"Chromebook" should be renamed to "Chromebrick"
quotes From the "Hardware Requirements" page on that linked FreeNAS site:
• "64-bit hardware is required for current FreeNAS releases. Intel processors are strongly recommended."
• "8 GB of RAM is the absolute minimum requirement. 1 GB per terabyte of storage is a standard starting point for calculating additional RAM needs, although actual needs vary. ECC RAM is strongly recommended."
The example configuration for a "Home Media Server or Small Office File Share" even suggests "16 GB RAM".
I've heard that ZFS is quite RAM hungry, but c'mon, 16GB for a home media server?
on the other hand, the big cost factor that would restrict home delivery to people who have money is… human labor costs. Once robot-based delivery is the standard, home delivery may be quite affordable. Maybe even less costly on the whole than operating supermarkets.
The latter doesn't contradict the former. What the market will bear results from all the individual subjective value assessments of every individual.
Indeed the market is made of all people, each with their personal and subjective assessment of value based on their own personal/subjective needs, criteria etc. What a product is worth TO YOU is your decision alone… and totally subjective, and… statistically irrelevant to the market at large.
The objective value measure though that matters to the market at large is: for what price can you be certain to find a buyer (in other words: "what the market will bear").
You realize that Qt is dual licensed
what part of the thread did you not read? We've covered that already: the other option is the closed commercial license which since the switch from Nokia to QTCOM has become exorbitantly expensive
Nobody cares about license cost of Qt (…) We don't use LGPLv3 in Qt. We buy commercial license.
You sound like you work in Qt Marketing, not in embedded.
It's quite low compared to everything else
That's rather ridiculous. Most alternatives cost zero.
don't know which version
apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:
https://www.copperspice.com/docs/cs_overview/timeline.html#t...
What I did write was that they switched their licensing default for most new modules from LGPL to GPL. So unlike Qt Quick (the original 2D Qt Quick) which was started under Nokia and licensed LGPL (or commercial)… the new Qt Quick 3D (*) was never licensed under LGPL but is licensed only under GPLv3 (or commercial).
It just so happens that the biggest part of my work is in embedded. And while it's obvious that QTCOM is trying to establish itself in that domain… this here is merely wishful thinking:
Your TV, car, Television, have Qt in them
no, actually neither has. And let's face it: while QTCOM does have clients in those domains… it doesn't have any huge share in either. Most use simpler lower-level graphical libs. Apart from that, you'll notice that those are Domains that account for a small minority of embedded… and a very unrepresentative one in that TVs, cars and TVs, unlike most of the embedded market, are stuff that are built by big corporations. So yeah, QTCOM seems to just focus on those big fish only now, as opposed to Nokia's strategy. As for industrial automation: don't make me laugh. Qt is totally irrelevant there.
And yes, licensing problems ARE a good reason which is a sore point, ESPECIALLY in embedded (where in most use cases you can't just dynamically link for LGPLv3 like on a desktop but have the whole mess of the build chain and update management if you are to let the user replace the Qt version).
Qt use is increasing and it shows in the number of buying customers.
As if that was of any relevance to the question whether many Qt developers are switching. Given that commercial licenses are only used by a very small minority of the professional developers using Qt (most using open source Qt), themselves only a subset of all developers using Qt… the fact that that small minority is currently increasing while remaining a small minority… doesn't say anything about the proportion of still Qt using developers switching away.
Besides, the sustainability of a temporary increase of that minority is highly questionable. Of course QTCOM's pressure towards Pay-to-Play temporarily forces some of those who are still tied by all of their still-Qt-based code to buy Qt licenses as long as they haven't finished switching to a better alternative… but on the long term most of them quit too. Precisely because of that.
We'll see how that strategy of maximal monetization and maximally squeezing developers works out for QTCOM in the long term
Sadly, I fear Digia (and its owned spin-off, the Qt Company) will be the death of Qt:
Unlike Nokia, which bought Qt and opened it to a more liberal license (LGPLv2.1) because it saw it as a strategic platform basis to attract developers to its platform (that is, until the MS shill Elop was injected as Nokia's CEO and destroyed the company… and sold Qt off)…
… unlike Nokia, the Digia-owned "Qt Company" (now publicly traded as QT-COM on Nasdaq Helsinki) sees Qt as a direct revenue source to monetize to the maximum and developers as milk cows to maximally squeeze out as long as possible. And unlike Nokia, Digia's "Qt Company" does so in a quite unsustainable way. They enormously increased the prices of commercial licenses to a level that can only be qualified as extortion, and they do whatever possible to force developers out of LGPL and into Pay-to-Play:
they switched Qt's open source edition from LGPLv2.1 to LGPLv3… and they switched from LGPL to GPL or commercial only for most new modules, including QtQuick 3D.
The bottom line is: it's really going down the drain, and lots of developers of Qt-based programs and apps are drawn away and looking for something new. The need for a new modern and more liberally licensed cross-platform UI lib is bigger than ever.
Also, many devs are even switching out of Qt-based cross-platform development and back to separate codebases for OS-dependent native UI toolkits… which is kinda sad, though partly alleviated by some other factors (such as the similarities between Swift and Kotlin)
Qt isn't known for "using every C++ feature" at all. Quite to the contrary, as far as C++ goes, Qt is stuck in the old times BEFORE modern C++. And it really shows in the architecture, memory management and syntax. In fact, lots of Qt's non-gui stuff is precisely about features that were missing in standard C++ at the time and later found their way there, leaving Qt with its old non-standard stuff (including containers, smart pointers, etc) and its raw pointers everywhere.
Making a wrapper for Qt is not really any more complicated by Qt being written in (old-style) C++ than if it had been written in C. In fact, lots of languages do have Qt wrappers. As for Qt being object oriented… well, while that might indeed have been a problem for a language that is not… all your examples (rust, go, dart, D, ...) are, so that's hardly the problem there. Also, as far as the declarative and reactive goes: Qt does do that as well, and way better than any browser-lib-based webrendering engine (including mozilla's)
The real pain point with Qt is with its licensing at least since Qt was bought by Digia.
PinePhone (with even a real Linux system instead of Android) has a replaceable battery too and is 150$
Is it possible to import/convert KiCAD libraries? Library coverage of the gazillion of available components is something that takes a lot of work and time. Even KiCAD with its head start, and higher user count that comes with it, is still lacking a lot of components. So whatever one thinks of KiCAD's libraries or library management… it would still make a huge difference for the user to have an import function or conversion tools so as to not have to start pretty much from scratch as long as the library coverage is lacking.