Jump to content

Armbian net page


mistofeles

Recommended Posts

Great page, great work !

 

It would be nice if there were a note, wether a downloadable packet contains GUI.

Better still, if there were a list (dpkg -l) of installed packets.

 

I'm looking for a minimal packet like minibian for RasPi for OrangePi PC.

Link to comment
Share on other sites

Igor loves minimalism ;) On the download page the simple ">_" sign for Jessie means "minimal/CLI" and the display symbol for the Trusty image below means "desktop/GUI". So choose the Jessie image but read the FAQ before (you won't find it either, it's the white bar labeled "Questions?" below "Check forum for more info!")

 

If you're the type of guy parsing 'dpkg -l' lists, I would suggest looking better into our build system since we're providing the ability for experienced users to create their distro of choice: default packages can be edited if you know what you're doing (but things will break for sure if you do this the first time).

 

BTW: Before you start with tweaking/tuning defaults better stay with them and only when you experience problems think about tweaking something. There are months of effort contained in Armbian and the key to a more responsive/faster system is not stripping down the package list but reasonable settings. Armbian realises the "work smarter not harder" approach not only for humans but also for their SBC  ;)

Link to comment
Share on other sites

TNX !

I'm not a specialist on your level / branch, even though I have used Linux from the very beginning and built many kinds of lab systems.

I have learned to leave defaults stay as long as possible.

 

Minimal packets are important, when you build networked lab systems, which have minimal displays or keyboards or not at all.

Link to comment
Share on other sites

Minimal packets are important, when you build networked lab systems, which have minimal displays or keyboards or not at all.

 

That's not true, at least for Armbian. Our desktop images only have a 'few' more packages on top but behave nearly the same as the CLI variant. So when you don't need a GUI choose the CLI version. When you're not sure you can also use a GUI image (requires a larger SD card since the GUI stuff comes with quite a lot of dependencies) and disable/reenable the nodm service there with systemctl/service.

 

Every image is accessible without connected peripherals through SSH and/or serial console after the first boot. The only annoying thing when using a GUI image in this mode when you forget to disable nodm (the GUI) is that after some time the screensaver will start to keep one CPU core busy (was a little surprise for me since when I tested the new first boot procedures headlessly with GUI images I always wondered why the board started to get hotter after some time --> disabling screensaver or nodm helped)

 

So the only real difference between our CLI and GUI images is the amount of space they need on SD card and significantly higher load caused by a screensaver if you forget to disable it. Using a GUI image headless makes no sense but works perfectly (believe me, I monitored this stuff extensively and there's no difference once nodm is disabled except of available space on the SD card).

 

Two notes: 

  • Choosing the desktop image when in doubt might be the better idea since desktop images are built with GUI acceleration (you won't get this at the moment when upgrading a CLI image to desktop, but we're already working on that)
  • We've also already prepared an image creation mode where only a small part has to be written to SD card (bootloader stuff) and then the rest of the image loads through NFS from a server. Might ease the deployment of many Armbian equipped SBC drastically and requires just an ultra small SD card for the device in question. Not ready yet
Link to comment
Share on other sites

My reason to minimal packets is just space. When we build  device which must run for years, we take as large and good quality SD card as possible and minimise writings to SD. Still we have had some cases, where the card has worn out.

Linux GUI doesn't need much space, but still...

 

I read some of your discussions and found that you have made a lot of work with the temperatures, which normal user does not know what to do and buys larger cooler.

 

Your second note sounds good.

So if possible, it would be nice, if there were various kinds of 'rest of packet', lab-minimal, server, KDE, Gnome...

It is easy to add packets with dpkg, apt-get or whatever.

The most important thing (for us) are the drivers for GPIO and most common devices.

Link to comment
Share on other sites

My reason to minimal packets is just space. When we build  device which must run for years, we take as large and good quality SD card as possible and minimise writings to SD. 

 

In 2016, 8G card is considered smallest and cheap enough, which is overkill for most scenarios if we have data on SATA / elsewhere. Armbian is optimized for SD card out of the box. You won't see much writing to the card. Of course you can go further with optimization, have read only system, use ram as overlay, ... on Wheezy we use ram for logs.

Link to comment
Share on other sites

It is easy to add packets with dpkg, apt-get or whatever.

 

It's also easy to either delete these packets (dpkg, apt-get or whatever ;) ) or to customize our build system. It's really that easy if you've a 64-bit PC running any OS that virtualbox can run on. Then you're up and running in an hour and use your 1st image created from scratch 2 hours later: http://www.armbian.com/github/

 

Regarding your concerns: Simply take the CLI variant and be happy. I would suspect when releasing 5.05 we will also provide again a wheezy image (then you can use ramlog if you fear SD card wears out) but in reality that really doesn't matter since Armbian reduces writes to the card to the minimum by default.

 

Please have in mind that Linux isn't that primitive as most of the people think and that accesses at filesystem and at the block device layer are different things. With Armbian a temporary file that will be deleted within minutes might never hit the card physically. This is a great source of confusion (forgetting about the filesystem layer, caches, buffers and the like) and a great source of 'benchmarking gone wrong' stories :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines