You are not logged in.
Pages: 1
Okay, maybe it's not that big compared to other distros these days. But since it downloads everything from the internet while it's installing, why is it ~700MB? To be fair, I haven't tried installing arch without an internet connection, maybe if no connection is available it's installing directly from the iso but in that case wouldn't a complete network installer with a smaller size be better?
Offline
It contains all the software needed to boot and and repair a broken system for both i686 and x86_64.
Offline
Not everyone has a flatrate internet at 50mbs. (i do have 150/75mbs)
Also having a single iso for both arch's is very nice, since IF you do have multiple machines, of which some might be older, you can install Arch on all of them, without the need to download another ISO.
And if you call this big, have a look at the Workstation spin of Fedora, that is as small as ~1.4GB, either 32 or 64 bit ONLY.
Though its a livespin providing 'everything you need' (from their perspective, that is allowed within their FOSS philosophy).
This said, you can imagine that the Arch iso, provides ~350mb for 32bit, and ~350mb for 64bit.
The download of the basic packages, is just convienience if you have internet, so you have the latest packages for the base system, from which you may install a DE/WM of your choice.
hth
Offline
This said, you can imagine that the Arch iso, provides ~350mb for 32bit, and ~350mb for 64bit.
It is a fair bit more - there is some sort of overlay for files that can be shared between the two.
Offline
True that, but its far more easier to explain, and for general speak (as in: he gets a rough picture of the situation) it is still a valid statement.
Furthermore, those files that can be shared accross the two, are usualy significant smaller than the binaries that cant. (afaik)
Offline
Even my Smartphone does have 300mbit and im living in germany in the countryside.
If someone cant afford to download the archiso, he cant most likely afford to use archlinux itself. Just imagine updates and installation of new software, everything goes through internet (not to mention pacstrap itself).
I'd say that separating 32bit and 64bit causes more trouble without really an advantage.
Offline
Offline
You could offer compressed downloads for people on limited bandwidth, compressing with e.g. rar gets me from 658MB to about 476MB.
Even my Smartphone does have 300mbit and im living in germany in the countryside.
You forgot to mention you're limited to only a couple of Gb at that speed, and will be throttled to GPRS speeds afterwards. Not to mention living on the countryside means your DSL line sucks big time and there is no real alternative unless you're lucky and have cable (I don't).
That said, I can afford downloading the iso, and keep my systems up to date. I just need more patience to get there than someone on a 100MBit line. A size reduction of the iso would be welcome.
About the only trouble the separation of 32-bit and 64-bit isos bring is having to create and host two images. But I imagine nowadays most people use the 64-bit version only anyway. Those who are still on 32-bit hardware are probably a minority by now, so maybe offering two images would actually save bandwidth costs.
[ Arch x86_64 | linux | Framework 13 | AMD Ryzen™ 5 7640U | 32GB RAM | KDE Plasma Wayland ]
Offline
Yeah, it could be trimmed down. The thing is though that the 64-bit distribution contains libraries for running 32-bit applicarions. So if they decided to split the ISO into two ISO files then only the 32-bit distribution would be slim enough that it's worth noticing. The 64-bit distribution would only be a few megabytes slimmer if we want to maintain multilib support. They could release a slimmed down ISO that only has the basic software needed to install but requires internet access to install anything and as a result, only downloading what you need.
The current "big" ISO is really neat since you have access to a wide range of tools needed for repairing a system. It's also consideraly smaller than other popular distributions out there. Gentoo isn't much smaller, the minimal ISO is only like 35% smaller and it's less versatile than the Arch ISO.
Arch could use a netinstall ISO that only contains tools to boot onto various systems and then rely on internet access for the rest. Also make the "base" install more adaptable. For example, when I install the base package then I don't want the XFS or JFS tools when I don't have such filesystems. It would be nicer if it would only install the filesystem tools used by me. I only have FAT (for ESP) and BTRFS on my machine so I don't understand why pacstrap/pacman blindly installs XFS and JFS tools but doesn't install btrfsprogs or dosfstools which I think is much more common than XFS and JFS for home users. A smarter way of installing would be nice. If I have a Intel CPU then automatically install intel-ucode. I think you understand what I'm trying to suggest here. Don't have meta packages just contain a list of common packages but only include what's required to make the system boot and then append packages that is useful on the target machine. Evaluate target and only install what's needed even though it would only save a few megabytes of download and harddrive space.
Offline
I was going to create new thread for this same question, but then found this one.
I guess we can have minimal iso as an option at least, that would help many. For example, following may be provided,
1. regular combined 32 and 64 bit iso (current)
2. only 32 bit/ only 64 bit iso
3. minimal iso, that can boot, create partions and connect to internet, rest can be downloaded from net. (as such evern with nearly 700mb, sized iso all packages are downloaded from internet by default)
I understand this will increase some burden on developers, and finally choice is always theirs.
Last edited by Docbroke (2016-01-19 01:31:51)
Arch is home!
https://github.com/Docbroke
Offline
I only have FAT (for ESP) and BTRFS on my machine so I don't understand why pacstrap/pacman blindly installs XFS and JFS tools but doesn't install btrfsprogs or dosfstools which I think is much more common than XFS and JFS for home users. A smarter way of installing would be nice.
I think you are misinformed... Run pacstrap with the -i switch and select only what you want to install from the defined groups you ask to have installed. There is no automatic install option that dumps out a predefined set of packages.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I was going to create new thread for this same question, but then found this one.
I guess we can have minimal iso as an option at least, that would help many. For example, following may be provided,
1. regular combined 32 and 64 bit iso (current)
2. only 32 bit/ only 64 bit iso
3. minimal iso, that can boot, create partions and connect to internet, rest can be downloaded from net. (as such evern with nearly 700mb, sized iso all packages are downloaded from internet by default)I understand this will increase some burden on developers, and finally choice is always theirs.
You can always make one yourself. https://wiki.archlinux.org/index.php/Re … nstall_ISO
If quantum mechanics hasn't profoundly shocked you, you haven't understood it yet.
Niels Bohr
Offline
I just realized Arch doesn't fit in a normal CD any more. That's disappointing.
Offline
You can always make one yourself. https://wiki.archlinux.org/index.php/Re … nstall_ISO
This is not what I was asking for, the purpose was to reduce download size of archiso.
Arch is home!
https://github.com/Docbroke
Offline
I think it should be really cool if a "slim" ISO being made available by the official channels, no? It was just fine 300mb
Last edited by abarahc (2016-03-16 14:39:59)
user@localhost $ grep -rnw "." -e "hacking"
Offline
Smaller ISO = more room for unicorns ... centaurs are optional. It's about time to blame Allan, surely?
Offline
Smaller ISO = more room for unicorns ... centaurs are optional. It's about time to blame Allan, surely?
Yeah, but the modified "filesystem" package wasn't approved for core yet.
More room for unicorns doesn't help if we don't actually have unicorns to add -- right?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I think i'm doing something wrong because i download 700mb and when enter the pacstrap i had to download additional data
user@localhost $ grep -rnw "." -e "hacking"
Offline
I think i'm doing something wrong because i download 700mb and when enter the pacstrap i had to download additional data
It's a net-install. This is correct.
Offline
I don't see any serious answer here. So this is just out of laziness? Because it was not this way four years ago or so. It was something that changed recently and I can see no advantages to this approach.
Offline
I don't see any serious answer here. So this is just out of laziness? Because it was not this way four years ago or so. It was something that changed recently and I can see no advantages to this approach.
Check these:
https://bugs.archlinux.org/task/48997
https://lists.archlinux.org/pipermail/a … 03691.html
Offline
I don't see any serious answer here. So this is just out of laziness? Because it was not this way four years ago or so. It was something that changed recently and I can see no advantages to this approach.
I see several serious answers here. In what way do you find them lacking?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I don't see any serious answer here. So this is just out of laziness? Because it was not this way four years ago or so. It was something that changed recently and I can see no advantages to this approach.
This was discussed, there was a vote. If you want to be part of such decisions in the future, subscribe to the mailing lists, where the development discussions happen. You could have found all of this out by yourself, instead you chose the drunk heckler approach. Good job.
Offline
Other than what's already been proposed / explained on links in #21,
As I happen to test install OSes on older / problematic hardware I found this solution to be convenient:
GAG[1] boot loader on a micro 50 MiB CD (e.g. UBCD has GAG) -» boot any foss OS with any size from a (multiboot) USB stick.
Very flexible (and easily done) in my experience.
EDIT:
[1] It's PloP boot loader not GAG, my mistake, both have funny names
Last edited by kozaki (2016-07-20 10:28:42)
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
Remember post them in the mailist relevant in post 7, not all dev real the forum and even the forum can go with a nicer solution but since no one propose it in the mailist this could just get ignored.
EDIT: allan is here just to provide brokeness and broken ness
Well, I suppose that this is somekind of signature, no?
Offline
Pages: 1