Which Linux distributions do you use?

[techhelpbb]

Originally Posted by Greg McKaskle

My point is, it doesn't hurt to ask "why" or "what would it take" questions. Those typically lead to good investigations and research and learning. But assuming something is simple can make trivialize the other people's work.

Greg McKaskle

With the changes to the GUI in Windows 8 and the end-of-life of Windows 7 all but an eventual assurance. No alteration in course from Microsoft's code name 'blue'.

What would it take to port the DS software to Linux legally in FIRST circles?

(I realize this diverges from the original topic so taking it to another topic is probably realistic.)

[Greg McKaskle]

I feel like we now have several threads about the ifs, whens, and whys of porting the DS to linux. As answered before, it is technically doable, but the testing and support effort need to be considered as well.

I think this thread about the variety of distributions in use acts as an interesting data point. Which distribution(s) would the DS target?

Greg McKaskle

[techhelpbb]

Originally Posted by Greg McKaskle

I feel like we now have several threads about the ifs, whens, and whys of porting the DS to linux. As answered before, it is technically doable, but the testing and support effort need to be considered as well.

I think this thread about the variety of distributions in use acts as an interesting data point. Which distribution(s) would the DS target?

Greg McKaskle

I proposed for the 2015 control system that instead of trying to pick a distribution to install on top of, that perhaps FIRST should 'own' a distribution to create a foundation for their own.

In the spirit of Edubuntu and the like: Other-educational-systems.

There is obviously a set of relationships to somewhat narrow choices:
RedHat, CentOS, Fedora
Debian Linux, CrunchBang, Ubuntu, Mint

Then there's possibly just as important a question as to what graphical shell (window manager) is a better choice.
Really also a question of whether FIRST considers Qt(with the possible commercial entanglement) or something else.

In any event, because FIRST would need to train people I figure they need at least some assurance that there is some consistency and that may best be served by 'owning' a fork. Just as Mint has come up a frequent choice in this topic yet it is derived from Ubuntu.

[floogulinc]

Desktop - Lubuntu
Laptop - Crunchbang (setting it up right now for competition tomorrow lol)
Almost any server we use/have - Debian Stable

Also, for development we use Sublime Text, Git, and UCPP (with SublimeFIRST).

[jhersh]

Originally Posted by Greg McKaskle

The third item, along with the custom firmware were made by an NI employee -- in volunteer mode.

Actually 2 custom firmwares... One for the communication / debug chip and one for the application SoC.

One easy way around this would be to ask for a board with a simpler interface.

Joe

[rbmj]

Originally Posted by techhelpbb

Then there's possibly just as important a question as to what graphical shell (window manager) is a better choice.
Really also a question of whether FIRST considers Qt(with the possible commercial entanglement) or something else.

Qt has been FOSS (LGPL) for quite some time now. There is no longer any sort of commercial entanglement.

In any event, because FIRST would need to train people I figure they need at least some assurance that there is some consistency and that may best be served by 'owning' a fork. Just as Mint has come up a frequent choice in this topic yet it is derived from Ubuntu.

'owning' a fork seems like a lot of work when they could just pick a stable base (such as debian or centos) and build on top of that.

W/R/T all of the Cyprus issues, are there really *that* many teams that actually use that feature? I know some do, but I feel like 90% of teams don't use it, and most of the teams that do are advanced enough to move to a different platform if necessary (if they're following the rules they have to rewrite everything each year anyways...).

[techhelpbb]

Originally Posted by rbmj

Qt has been FOSS (LGPL) for quite some time now. There is no longer any sort of commercial entanglement.

I just spoke with Digia about this exact matter less than 2 weeks ago.
There is an issue there and before anyone assumes anything, they best speak with Digia about it. I'm sure FIRST will do any due diligence required I have no need to speak for them.

[techhelpbb]

Whenever I scroll a post down all the content disappears.
So I have to post twice, sorry.

Originally Posted by rbmj

'owning' a fork seems like a lot of work when they could just pick a stable base (such as debian or centos) and build on top of that.

The issues are going to be more subtle. FIRST switches back and forth between static IP and DHCP. Things like 'Gnome network manager' won't play well with that universally. Then there's going to be the introduction of interface changes that might be adverse to FIRST's needs that a stable base can change without a second thought.

At some point when you start bundling up specific versions of things with specific requirements you are as much a fork of Ubuntu as Mint. We could discuss where that point is at length, but I suspect that point becomes more cogent when your organization has specific requirements and won't comply with the changes (ether immediately or ever). At that point there is autonomy involved.

Annoyingly I can blind type and it appears when I click save...so:
1. I support using Linux because it means that it removes the licensing issue Microsoft/OSX introduces on the team's end.
2. I support using Linux in the sense that it likely means more open code base.
3. However, I was just the CSA in Mount Olive and I worry that asking people to downgrade and upgrade packages is going to be a bit more work than asking people to limit the cameras to 320x240x15fpsx50% compression.
Even with lots of shell / Python to reduce the interaction. So realistically I think FIRST should have version control on everything that might impact them so their QA is more thorough.

[Ido_Wolf]

Originally Posted by Greg McKaskle

I feel like we now have several threads about the ifs, whens, and whys of porting the DS to linux. As answered before, it is technically doable, but the testing and support effort need to be considered as well.

I think this thread about the variety of distributions in use acts as an interesting data point. Which distribution(s) would the DS target?

Greg McKaskle

Linux Mint, and Ubuntu's variations will probably be all the same or at least very similar releases, and then an additional release for Fedora will probably cover most FRC/Linux users.

Another solution would be source code releases, but we're still talking about proprietary products at the end of the day so...

[byteit101]

Originally Posted by Ido_Wolf

Linux Mint, and Ubuntu's variations will probably be all the same or at least very similar releases, and then an additional release for Fedora will probably cover most FRC/Linux users.

Another solution would be source code releases, but we're still talking about proprietary products at the end of the day so...

I tallied up this thread a week ago and found this:

(ubuntu + lm) ~ 35%
debian ~ 30%
fedora ~ 15%
Arch ~ 10%
Gentoo ~ 5%

The debian family is usually fairly similar, so you can safely say debian family is 2/3 of the total.

[codes02]

Originally Posted by Ido_Wolf

Linux Mint, and Ubuntu's variations will probably be all the same or at least very similar releases, and then an additional release for Fedora will probably cover most FRC/Linux users.

Another solution would be source code releases, but we're still talking about proprietary products at the end of the day so...

Source code releases aren't the same as an open source development model. My opinion is that most of the gain for the company doing the release is only seen if they actually develop in the style of an open source project: clear route for patch inclusion, licence to encourage contributions, and open development practices.

Also, can you clarify what you mean by "proprietary products at the end of the day"?

Edit: ah, got it: source code releases was for multi-distro support purposes. I'll leave my comments, but they are now mostly irrelevant.

That said, other binary products (nvidia's drivers, eagle, and oracle's jvm, for example) have no issue running on whatever linux they are thrown at. I advise caution in building a DS towards a particular linux distribution. Don't assume so quickly that targeting it in that way is a requirement.

[davidzz123]

My first Linux Distribution was Ubuntu and after a while a got bored, so I researched and installed ArchLinux. I really recommend this distribuition, it is a interactive way to learn more about Operating systems and how they work.

[Ether]

Pardon the brief thread hijack, but I guess there are probably some Linux gurus here. Quick question if I may?

can dd write an output file to a ntfs file system?

for example, I want to save an image of the MBR on sda to a file in a folder in sdb1, where the file system in the sdb1 partition is ntfs:

dd if=/dev/sda of=/mnt/sdb1/MBR.img bs=512 count=1

Will this work, and not corrupt the filesystem in the sdb1 partition?

[rbmj]

Originally Posted by Ether

Pardon the brief thread hijack, but I guess there are probably some Linux gurus here. Quick question if I may?

can dd write an output file to a ntfs file system?

for example, I want to save an image of the MBR on sda to a file in a folder in sdb1, where the file system in the sdb1 partition is ntfs:

dd if=/dev/sda of=/mnt/sdb1/MBR.img bs=512 count=1

Will this work, and not corrupt the filesystem in the sdb1 partition?

dd only sees files. As long as you can write to the location, it won't corrupt anything. It's only dangerous when your output file happens to be directly mapped to disk.

[Ether]

Originally Posted by rbmj

As long as you can write to the location, it won't corrupt anything.

I guess that was my question. Can dd safely create (and write to) a file on a partition whose file system is ntfs?

Or will it try to create the file, and wind up corrupting the file system because ntfs is not supported?

The target ntfs partition is on a USB external hard drive, if that matters.