With full steam into the new year!


oh, and, of course, showing the handoff from EvilDragon to zmatt (or whoever it's going to), with sparks flying, ghosts emerging, and that sort of thing.
 
Did you ever have a chance to install the proper OS image? I'm sure we would all love to see more of this running/working near-final prototype in action.
In case you're stuck with the test image for some reason (e.g. because it comes with your prototype), do this to get a proper LXDE desktop:

1. fix the display rotation in software:
create a file like this (ref: [1]):
Code:
# cat /etc/X11/xorg.conf.d/1-fbdev.conf
Section "Device"
   Identifier "LCD"
   Driver "fbdev"
   Option "fbdev" "/dev/fb0"
   Option "Rotate" "CW"
EndSection

2. "unblacklist" systemd (a lot of packages depend on it) by removing this file:
/etc/apt/preferences.d/systemd

3. Get rid of the pid warning popup:
a. remove this line from /etc/inittab:
Code:
X1:23:respawn:/usr/bin/startx
b. install a login manager like nodm (if you don't want a login mask) or slim (if you want one).

All three items work for me if I boot the test image on my Cubieboard2.
(Well, of course #1 actually "breaks" MY display because the image that is displayed on my TV now stands on it's side. But it will cause the image on the Pyra display to be upright.)

[1] http://unix.stackexchange.com/quest...-rotate-the-xf86-video-fbdev-during-execution
 
@sulu , The OMAP5 uses TILER, I don't think fbdev works or it's slow. Currently the only way of specifying rotation is in the DT binary, the rest is a bit hacky.
 
My bad! I wrongly remembered, that ED did not only put a generic rootfs on his prototype, but also a rather generic kernel. At least I somehow assumed it runs fbdev.

btw:
What's the deal with this video [1]? It shows a desktop of a system running a kernel called "4.7.0-letux-pyra-r+".
Is it your's? The player name in the Starcraft video of the same youtuber might suggest that.

Code:
[1] https://www.youtube.com/watch?v=3JgXfiKglfQ
 
What's the deal with this video [1]? It shows a desktop of a system running a kernel called "4.7.0-letux-pyra-r+".
Yeah that's my video.

I'm using that specific older kernel that has all the right Device Tree hacks to let TILER rotate the screen. It was put together by aTc and included some changes from zmatt. I'm also using fbturbo not fbdev as an Xorg driver. It's also not the kernel with all the latest fixes for the actual pyra. there are newer Kernels out in the wild.

zmatt and aTc could explain all this better than I can, I just make videos of it working.
 
Maybe I missed it, but was there an answer to sulu's question?

I don't want to get into one of these boring lengthy arguments, but was there a technical reason for not enabling Systemd on the Pyra, apart from having a minimal test image?
 
Maybe I missed it, but was there an answer to sulu's question?
Sort of.
On the pictures of the Pyra prototype we see a rootfs running that hns uses for testing. This rootfs dates back to a time when there was no Systemd. And since it is easier for him to debug SysVinit than Systemd there was no reason for him to change the init system. To make sure this change doesn't happen accidentally he blacklisted Systemd, which turned out to be a bit overzealous.

We don't know yet if the final Pyra OS will ship with or without Systemd as an init system, but from our POV as end users/customers it doesn't really matter beyond personal preference as long as it works.
So currently there is no reason to assume, that there will be Systemd-related problems on the Pyra. To be precise though, there is no proof either, that there won't be any problems.
So the strict answer to my question was: "No."
 
So currently there is no reason to assume, that there will be Systemd-related problems on the Pyra. To be precise though, there is no proof either, that there won't be any problems.
So the strict answer to my question was: "No."
We've been running Systemd on the devboards since jessie was testing. aTc plans on using systemd, having him rewrite all the init stuff at this point seems like more work.
 
@TrashyMG:
Can you please test if phonefsod [1] and libphone-ui-shr [2] run stable on the devboard?
Without a GSM modem you won't be able to fully test the software of course, but I'm mainly interested in knowing whether phonefsod and the underlying fso daemons run at all and whether or not you can make SHR crash or show otherwise strange behavior by randomly clicking buttons in the UI.

[1] https://packages.debian.org/search?keywords=phonefsod&searchon=names&exact=1&suite=all&section=all
[2] https://packages.debian.org/search?...&searchon=names&exact=1&suite=all&section=all
 
Thanks for clarifying.

I'd count myself to the users who would like to have systemd, as I'm used to it on the desktop :) Also boot times should be better than with SysVinit, shouldn't they?
 
Depends. On my desktop, systemd takes about three times as long to boot as compared to sysvinit. On a friends laptop running ubuntu, systemd is slower than upstart. But supposidely, it's quicker for some. I consider boot times a stupid argument for one or the other, computers today are so fast anyway that nobody cares. Only if you do development work that requires you to reboot tens of times a day wouldv I consider it an argument, while most users of the pyra probably will play the endless game of plugging in the charger before the battery running out :p

Systemd happened to be what was used to set up the pyra-specific customizations, so that's what'll ship.
 
Depends. On my desktop, systemd takes about three times as long to boot as compared to sysvinit. On a friends laptop running ubuntu, systemd is slower than upstart. But supposidely, it's quicker for some. I consider boot times a stupid argument for one or the other, computers today are so fast anyway that nobody cares.
And yet there are users claiming to use "non-bloated" desktop environments because they take less time to start :). I agree that too much of the conversation revolves around boot time though. I use it because of the nice tooling. I know everyone doesn't like it, but I find it nicer to have a set of sanely named basic tools with a consistent interface than a hodgepodge of separate ones with imaginative names, configuration conventions, documentation and command line switches. Of course if one is already grown accustomed to some set of tools it's hard to let go, but if you can it may turn out for the better in the long run. Anyway, let's not turn this into yet another a systemd thread. If someone insists on having a say, let's move to one of the pre-existing ones.

Am I the only person who remembers when months long uptime was a badge of honor? How often are you people rebooting that it's a design consideration. :p
For servers yeah, but for anything else I tend to keep them in the lowest energy consumption state convenient whenever they're not in use. Keeping, say, a desktop computer on at night just for the uptime doesn't come off as practical, at least. I boot once or twice per day, typically, depending on the upgrades available.
 
I turn all of my x86 computers off at night, as their fans are too noisy. My Pandora on the other hand only gets explicitly rebooted when there's a new SZ release, and accidentally when I forget to charge it every other day and it runs down overnight (it's got no screen, so I can't check it before bed unless I wire it up to the TV).
 
I turn all of my x86 computers off at night, as their fans are too noisy.
Funny, I have trouble sleeping without the sounds of my computer fans whirring. plus no heat in my room, it helps keep the room sort of warm in the wintertime.
 
That's what suspend is for.
I don't normally do this but I did for you. I shut off my computer. I did this to plug in my kill-a-watt. While it was booting it reported about 90 watts. Starting up Chromium it spiked to about 150. Once that was all done and it was idling, it read 70 watts. And then I suspended it. All non-essential systems shut off, just enough power to keep the RAM alive. Kill-a-watt read 2. 2 watts. That's 500 hours to attain 1kwh of energy usage. 8760 hours in a year means that if you never used your computer at all, if it just sat suspended 24 hours a day all year, you would consume about 17.5 kwh. The average household in the USA uses 10800kwh per year, meaning that your PC would be consuming 0.16% of your total power usage: one sixth of one percent of everything you use. While this is not zero, it is practically negligible and you need to do some real cost analysis before making decisions based on boot times.
Assuming an average cost of 12 cents per kwh (according to google), that's $2.10 every year. More realistically, let's assume half that: you boot up your computer at 8am and shut it down at 8pm, thus it's only "wasting" $1.05 every year. Is the time it takes to shut down and boot back up again every day all year worth $1.05?
 
Ever since I set up wake on lan on my desktop, I'll just wake it up right before I get up, it's all booted by the time I'm on my chair. I never turn off my laptop, although I probably should, to keep maintenance costs on it down.
 
Funny, I have trouble sleeping without the sounds of my computer fans whirring.
A friend of mine used to have a beefy dual-socket 1HE server he got for cheap because some intern dropped it and damaged the front cover, which canceled its support contract or something like that. He didn't mind sleeping in the same room at all, but he wasn't able to hear his alarm clock anymore. Placing it on the floor was a great replacement for the vacuum cleaner, though.
 
Back
Top