Posts made by dobey
RE: essential software proposals for ut
You can create a libertine container and install any console based tools you want to use, which are in the Ubuntu 16.04 archive and available for the phone's architecture. Though, terminal apps on a phone will be difficult to use, and hardly qualify as essential software.
Remember, UT is not a traditional PC Linux distro.
You can probably install and run some of the other legacy GUI apps in libertine and use them as well, if they work, but if they are not built to scale properly and deal with touch based interface, they will be difficult to use. Also, legacy GUI apps in libertine won't have accelerated video, so they may not perform very well either.
RE: Google sheets
developped to work with chrome, I'm not sure it's W3C compliant.
Morph uses QtWebEngine which is a fork of Chromium, so this is basically irrelevant.
Though indeed it is not clear what @wdnp2 is trying to say here. It seems there is no webapp in the store for Google Sheets (or Docs), but they should all be accessible from the Drive, Mail, or Calendar webapps (since Google has links directly to such places on those web sites).
RE: hardening morph (browser)
RE: hardening morph (browser)
@domubpkm Just to clarify, but public VPN services like Nord, PIA, etc… do not necessarily improve the privacy of your browsing. It just routes your traffic through a different single point instead of your ISP. Whichever such service you might use is also still subject to the laws of whatever governing bodies it operates under.
They can be useful to access otherwise region-blocked services, and such, but they do not inherently improve either security nor privacy of your connection to those services. So might be useful for some, but I definitely wouldn't put such VPN services under the category of "hardening" a system.
RE: tmpfs for ~/.cache?
true, but it should also be mentioned that space is allocated dynamically, no data = zero disk space. the whole idea behind a tmpfs for /.cache is a further bit of privacy (perhaps security too?), starting off with a clean cache on every reboot.
There will never be no data, as Qt writes cache for QML compilation and other things to it. I also don't think it will really increase privacy or security. Confined apps already can't read data from other apps, only their own cache, so this won't change anything in that respect. It sounds like a workaround for other problems in that case.
another benefit could be an increase of speed, ram is faster than any traditional data carrier. after all, this is about mobile phones and not classic desktop enviroments, so it also depends on the device ut is running on, no doubt.
Rather you will actually end up with the opposite, as RAM will fill quickly with QML and image caches from apps, and because these caches will need to be rebuilt all the time, apps will be slower to start and use. And indeed we're talking about mobile devices, so you don't have 64G of RAM, but more often 1-2, or a 3-4 on most newer devices. Some higher end devices might have more available, but still nowhere enough to make this a useful thing to do. Also, as mobile devices are already using solid state storage, read/write speeds aren't a huge hindrance, unless you're using a bad app which is constantly hitting disk, which shouldn't be done (every write to disk reduces the lifespan of the storage).
RE: tmpfs for ~/.cache?
@utouchuser Well, tmpfs is just a RAM disk. So anything you put in a tmpfs mount, will take up space in RAM. You will be rebooting quite often if you make
~/.cache/a tmpfs mount, and actually use the phone at all, especially if you want to download anything, for example.
RE: support for led notifications
It contains a class DefaultStateMachine that also keeps track of state and for example takes care of the display dimming and turing off.
Yes, repowerd is the thing which tells the hardware what to do here. It is the implementation for such pieces of hardware interaction. It is not where policy is decided though. It is simply told when the display should be dimmed or powered off, when an alarm event should be triggered, etc… It is itself not a full stack.
I guess repowerd can also listen to this signal.
No, repowerd should not implement any part of indicator rendering.
I'll gladly move the led stuff stuff somewhere else but the current unity place (qml\Panel\Indicators\IndicatorsLight.qml) feels like the wrong one
It may not be the right place, but it is a sufficient one for now. There's no need to move the "should the LED be enabled, and how" to somewhere else. The only part that should be moved to repowerd is the part that actually turns the LED on, off, blinks/pulses it, and such. It should not do more than that.
A friend of mine (owned a ut-phone) suggested the lockscreen should manage the led state.
Friends and users do not developers make. The lock screen is definitely the wrong place. The current location is fine for the level of refactoring which needs to be done now, to achieve what you want. There's no need to grow things beyond their need yet.
If it is decided that the led indicator is usefull and should be part of ubports then indeed configurability should not be overdone. Some already existing config file would allow things to be disabled if really needed.
There is no need to worry about this level of configuration yet, to achieve the immediate goal of charging/charged LED status.