Natela
Natela on Hacker News
It's not open limitations but about extra Microsoft spyware included and making you agree with Microsoft Privacy Terms
https://code.visualstudio.com/License/"The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation."
Samsung didn't implement convergence, they implemented Android-with-a-keyboard-on-a-big-screen . True convergence would be something like Ubuntu Touch wanted to do
But what is this price we pay for FB and Google services ? 3% increase on 0€ is still 0€.
We don't pay for Google with money but with our privacy. I'm perfectly fine with making my privacy more expensive to buy for Google.
As a European I think this is a smart move on the contrary.
Google cannot get rid of the EU market, if it does, EU competitors might have a chance.
So the EU can just tax Google as much as it wants. What are we to be afraid of ? Google leaving EU ? Please do ! This will only gives us a chance to come we our own solution to the web Google&FB think they invented.
I don't get how we could not be glad that we tax more those dystopian companies. Google, FB, etc... don't respect any values of privacy and freedom, they should not have even the right to do what they do in EU and GDPR is step in the right direction for that.
The only problem is that we have no weight if we don't act together, so if some European countries are too short-sighted and put their self little short term interest above the rest and prefer offer encourage Google's development, then yes we will fail.
I just hope it will be easy to write bindings for different language in the future. I guess it's important for a wider adoption not to impose something "low-level" like Rust (for eg QT has QML/JS, GTK has bindings to Vala, Python, etc.. Flutter uses Dart, etc...)
I really wish all the best for this project. To me here are the main points why this framework is really promising :
- Backed by webrender : Mozilla is putting large effort in webrender and Azul leverage all this work by using it as a backend. Too early to say, but it can potentially be far more performant than QT or GTK
- the "modern" way people do UI : you have Dom diffing backed-in like React (and like Flutter)
- backed-in data binding
- (live) CSS styling which is a subset of web CSS
- SVG support
- Extendable : you can use OpenGL to draw to a texture and pass it to Azul for display. This will allow for integration of 3D renderer, 2D renderer (for e.g Azul SVG drawing is using this mechanism), etc...
I'll definitely follow the progress with a lot of attention. I personally would prefer Azul so much more to GTK/QT/Flutter for developing apps
I agree, I think Typescript is a very good pick for UI developpement, it's easy to use yet you still have types that help with maintainability. I would definitely be using something like this to develop apps :).
However there are people who prefer other languages so it'd be nice if we could have a WebRender UI framework on which we could write bindings for any language, similarly to QT and GTK that have bindings for several languages.
This is a nice experiment ! There are a few people starting to hack around with WebRender. There are already Limn, Azul, Stylish, etc...it would be nice if we joined forces in developing one good UI framework powered by WebRender.
Yea and this is purely driven by Apple needs. For e.g on Apple the UI is desturated so dark mode just means go darker. But for e.g on Linux with Arc theme, dark theme has a blueish tint, so the website using dark theme will look bad on Arc theme desktop.
We should at least add the option hue & saturation to light/dark setting. Then the app/website would at least fit color-wise with the theme of the OS. But only dark/light is assuming all themes are desaturated which is true for Apple but not necessarily for other platforms
I have a PH1, I got it new for 400$. It is by far the most premium experience you can have out of all Android phones for that price. 128GB, excellent screen resolution & contrasts, good perf, very nice looking, clean Android, etc...
The camera has been improved. It is not the best camera on the market but still quite good. They are 2 camera so you can have depth of field.
I don't have any complain except the lack of jack and Wireless Charging
Security-wise it will depend on the distro. Under Gnome /KDE it will be flatpak responsible for sandboxing. So it doesn't depend (too much) on Purism. On the hardware side they put way more effort (at the price of perf maybe ?) than other manufacturer to avoid backdoors.
React is not fast, clearly the simple idea of having a virtual Dom is very costly compared to do things by hand. However for a large scale app react makes it more easy to reason about and keep it maintainable, components are far easier to implement, etc...
So for many people, the benefits you get on the development side outweight the performance overhead
I agree very much. However there are two points that make it difficult :
- Virtual Dom. It simplifies a lot the creation of components. And components that are made for a VDOM are very different from those made without VDOM in mind.
- Data Binding. There are multiple ways to bind data to your components, once again this might influence the way components are made.
Those are not standard, some people like VDOM other not, and not everybody want to bind data the same way. So if we all contributed components in vanilla JS / Web Components, this still doesn't solve what should the API of those webcomponent look like.
There was already a post on this. Basically the argument about home is true but this is because 1) apps should not use filesystem access but rather portals (if they can) 2) nothing should be executable in the home folder (nobashrc, no script, etc...)
If I remember well the second argument was about update not being frequent enough.
So nothing fundamentally about Flatpak but more about the infrastructure (lack of updates) and the use of it (we should not allow home access and use Portals or we should disable bashrc).
with RSS it was decentralized, you could "follow" bloggers and website directly. Now news are own by big companies like FB or Twitter and it's kind of sad. If you want to follow someone you have to comply to FB or Twitter
Ideally , Firefox would be downloaded from official Mozilla Flatpak repo, Blender from Blender Flatpak repo on Blender server, etc... And we would have this list of those repo on our distro.
However because the official adoption is slow (very few software have official flatpak repo), flathub allowed the community to build packages themselves. But this is clearly not how it should be.
The second (more legit) reason of flathub is that small developer might not want to pay a server to host their app and flathub proposes to host their repo.
Thank you ! This should be 1st. Many people don't understand this it seems
No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos.
It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps
What ? No it's exactly the opposite ! I think you're confusing with AppImage maybe which is indeed download from the browser & run.
The (long) goal of flatpak is that the user would never download and execute from the browser, everything is updated through the flatpak repos (like the PPAs for .deb) but with the addition that the apps are sandboxed and follow a runtime model for dependency instead of packaging everything or depending on other packages.
Basically the goal is to have something like on Android or IOS , so exactly the opposite of the "download from the browser and run an untrusted executable"
The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps.
(Of course in practice as soon as you are programming a bit you'll want to open a terminal, run scripts and do stuff outside flatpak)
For the second point, well it's just that update are not frequent enough ? This has nothing to do with flatpak technology right ?