VSIDO 32bit & 64bit ISO’s updated 2017-MAY-01 16:40 CST

VastOne


  • Corrected the 'gave up waiting on suspend/resume device' issue on boot
  • Standard 2 week release cycle, all cylinders running smoothly
  • Updated all applications to the latest SID levels

All changes can be seen and discussed in the VSIDO Change sub forum

All files and torrents can be downloaded from the VSIDO Download page
VSIDO      VSIDO Change Blog    

    I dev VSIDO

PackRat

Download when smooth and the Sha256sum checked out.

Other than being uEFI capable, are there other differences between the uEFI x64 and the regular x64? If the uEFI iso will install on a BIOS machine, is there a reason to have both x64 images? Save yourself a bit of work/time.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

VastOne

^ Good question... I can install to normal hw with the uEFI ISO but something goes amuck with grub.. I get the grub rescue screen...

Except for space and obviously the time to build, test and upload, it really is no big deal... I kind of like having them separate... 
VSIDO      VSIDO Change Blog    

    I dev VSIDO

filip

Quote from: VastOne on May 02, 2017, 12:45:07 AM
^ Good question... I can install to normal hw with the uEFI ISO but something goes amuck with grub.. I get the grub rescue screen...
...

That's the GRUB EFI vs GRUB BIOS issue.
See, having any GRUB variant preinstalled on the Live squash.fs image essentially locks you to that variant ( BIOS or UEFI ).
Installer, on the other hand is designed with the single ISO supporting both in mind, and works in the following way:

1. You don't have any GRUB installed @squash.fs
2. You do have all grub packages, "efibootmgr" and "os-prober" in the "support" dir on the ISO image root.

Then, during installation installer sets up a temporary Apt repository from the ^"/support" and installs apropriate GRUB for the machine from there.

Btw, installer-wise, there's nothing wrong with the separate ISO's aproach, except for that "issue" of being usable only for the targeted machines/BIOS types. :)

VastOne

Great info and explanation Filip... Thanks mate

I do not mind the extra half hour of build and test time to have a uEFI option.. IMO a better question is why on earth is there a need for a 32 bit version at all

Lets debate that one
VSIDO      VSIDO Change Blog    

    I dev VSIDO

filip

Quote from: VastOne on May 05, 2017, 11:52:08 PM
Great info and explanation Filip... Thanks mate

I do not mind the extra half hour of build and test time to have a uEFI option.. IMO a better question is why on earth is there a need for a 32 bit version at all

Lets debate that one

Anytime! :)

@32bit:
Well, personally I don't care about it anymore, nor see any real use-case in the desktop arena for it.
I have a great attachment to my Athlon-XP machine ( that was my first ever CPU ), however the growing pains coming from the lack of SSE2 instructions and the abysmal performance ( browsers, gtk3 etc ) simply killed all the joy in using & playing with it, so I just gave it up post Deb Jessie.

IMO, 32bit has become, or is slowly but surely becoming a niche/legacy arch, and should perhaps still be supported by the big players only ( Debian et al ).
Of course, I'm not trying to be provocative or something, there are still legitimate use cases, and users that really need the 32bit, however those numbers are low and getting lower by the day to justify the effort required by the distro maintainers ( excluding major players who can afford it ).

And not to mention that using a 32bit distro on a 64bit capable machine is just a pure waste of resources and performance. Further exaggerated by the fact how cheap RAM is these days ( so "higher RAM usage for 64 bit" doesn't really hold any more ).

VastOne

What I may end up doing is keeping the x32 build platform up to date in the even anyone should ever need it but would only be by request.. it is a simple process that is pretty much scripted

I would then only maintain an ISO for standard x64 and uEFI x64...
VSIDO      VSIDO Change Blog    

    I dev VSIDO

filip

Quote from: VastOne on May 06, 2017, 12:38:46 AM
What I may end up doing is keeping the x32 build platform up to date in the even anyone should ever need it but would only be by request.. it is a simple process that is pretty much scripted

I would then only maintain an ISO for standard x64 and uEFI x64...

As far as I'm concerned, go for it! :)

Though you could also reduce the release frequency for 32bit to say, 3-4 releases per year or whenever some nasty breakages occur in Sid.
That way you'd provide a smoother transition for users, and eventually if nobody complains, ditch it all together or switch to "per request" builds only. :)

PackRat

Quote from: filip on May 06, 2017, 09:53:47 AM
Though you could also reduce the release frequency for 32bit to say, 3-4 releases per year or whenever some nasty breakages occur in Sid.

+100

This.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

VastOne

Would you agree with all releases at that pace or just the x32? I will make it the policy for the x32 now and schedule it every 4 months so the next will be done in August
VSIDO      VSIDO Change Blog    

    I dev VSIDO

hakerdefo

My two cents,
64bit = Twice a month
32bit = Once a month

Reasoning? Sid-the-naughty-kid rolls fast! So a fifteen day release cycle is perfect for 64bit. For 32bit you can release the build once every month. Anything more than a month and the user will have to download almost as much as the ISO size on the very first apt-get update, which won't be cool  :(

Cheers!!!
You Can't Always Git What You Want

PackRat

Quote from: VastOne on May 06, 2017, 07:27:48 PM
Would you agree with all releases at that pace or just the x32? I will make it the policy for the x32 now and schedule it every 4 months so the next will be done in August

Just the x32; say quarterly - that should keep the post-install dist-update manageable.

For the x64, the current 2-week or once a month should work. Hackerdefo is right though, Debian Testing/Sid rolls pretty fast if only because of the number of maintainers involved in the project. Not sure you could go for 4-6 months or longer like some of the other rolling releases do. Even Arch has gone to a monthly release cycle. About the time they went all-in on systemd - make sense, systemd (and wayland) are moving targets, doing a dist-upgrade on a 4-month iso could get ugly in a hurry.

Do you track the number of downloads per month?
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

VastOne

^ Nope.. no tracking.. It's a labor of love and nothing more

I think biweekly for x64 and quarterly for x32 is sufficient ... if someone steps up and complains about x32 being dated I can always change back
VSIDO      VSIDO Change Blog    

    I dev VSIDO