Live data from Hacker News

Arch Linux pulls the plug on 32-bit

pcworld.com

91–100 of 201 posts

Re: Arch Linux pulls the plug on 32-bit

#91

Earlier quoted context omitted.

I didn't flag you, I replied to you. That's my policy: If I disagree, I reply. I only flag trolls and spam, and I don't consider you either, just misinformed. Though, now you seem to be trying to pick a fight so I'm going to bow out. Cheers.

>If I disagree, I reply. >I'm going to bow out. Cheers. Thanks for acknowledging it, then.

...and now you are trolling. You edited out your original post, calling the people replying to you "Arch fanboys" (even though I stated my own disdain for Arch), reposted it with an addendum to make it appear you were talking about Upstart all along when you were initially only talking about systemd, and now you're paraphrasing me in a way that makes it look like I agree with you. Consequently, I have now flagged all of the above mentioned posts by you (the edited original, the "new" post, and this one I'm replying to) since it's obvious what you are doing. I still choose not to flag the one post you accused me of flagging, as others have already taken care of that.

Please consider how your actions in this thread make you appear, and have a good day.

Re: Arch Linux pulls the plug on 32-bit

#92
post #42
post #32

Earlier quoted context omitted.

What do you mean? The announcement specifically says multilib is unaffected. I run 32-bit programs all the time.

Multilib is different concept from x32 ABI. Typical usecase for multilib is running i386 binaries that use i386 ABI on amd64 system (or sun4m binaries on sun4u, mips32 on mips64...), x32 ABI is alternate ABI for amd64 that uses 32bit pointers, but all other amd64 ISA extensions.

Today I learned something. Thanks!

Re: Arch Linux pulls the plug on 32-bit

#94
post #73

Earlier quoted context omitted.

So to avoid re-opening the debate of Python 2 vs Python 3, let's take this point of view: The Python 3 language may, or may not, have been an improvement, and the transition from 2 to 3 may, or may not, have been done correctly. Everyone has its own opinion on this. But at the end this problem concerns the Python community. From the Arch developers point of view, the Python developers decided to release a new version…

Except that python says that python 3 should be an executable named `python3` and `python` should refer to `python2` [0] 0: https://www.python.org/dev/peps/pep-0394/

It says right in the pep

"...however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3..."

There was no guidance before the Arch devs made their choice. There's no reason to change back.

Especially since the goal is that python3 will be default eventually.

"...in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line."

Re: Arch Linux pulls the plug on 32-bit

#95
post #21

Good for Arch, I guess. Still, there's plenty of uses for 32-bit platforms. Also, much of the attractiveness of Linux (the kernel) and the GNU software has always been in their excellent support for various architectures and platforms. Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t) prompted by the inflated need in large address spaces lead to an ever more increasing demand for memory (due to…

All modern x86* CPUs are 64bit anyway and if this move means maintainers are freed up a bit, then I think it's worthwhile for the distro as a whole.

Arch isn't really meant to be that one distro you can stick on a PC from the early nineties anyway. There are much more suitable distros for legacy hardware.

And about the downsides of 64bit: I think the vastly improved address space offsets the improved memory use by orders of magnitues. My Desktop has 8 times as much useable RAM as it could have with 32bit - but 32bit datatypes are only double in size.

Re: Arch Linux pulls the plug on 32-bit

#96
post #24

It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances tha…

tl;dr - due to a CPU bug, you can't run normal i686 distributions on the Quark anyway, and support in mainline Linux is still shit 3 years after release. > Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices? I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering…

Thanks for your post (and tl;dr comment too - I need to work on being more concise :-). I own no Quark powered boards but have some friends who do. It's a shame that they fall into the category of boards with poor software support (and even more of a shame since they are based off the Intel architecture). I own a few raspberry pi's and have been extremely pleased that even my rPi model B+ from 2012 still gets support and updates (and hopefully will for a while longer now that the rPi zero exists with similar hardware). Friends would brag about the faster or cheaper O-droid, Pine-64 or Banana-pi, but with dismal software support, I couldn't justify even a descent performance boost. This reminds me of the little I know of the Android ecosystem, where a tablet I bought in 2013 is still stuck on Jelly Bean, while my 2012 iPhone 5 still gets updates. I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.

Re: Arch Linux pulls the plug on 32-bit

#97
post #84

Off topic: I've been in the market for a new laptop that runs Linux, I've never had a PC that ran Linux (closest thing was a Macbook running MacOS, I'm also discounting my work laptop that allows me to VNC into SuSe). After doing some research it seemed like Arch Linux might be a good fit, it seems like a very minimal OS that allows for great customization. However I'm unsure how user friendly it would be for someone…

Personally I started out with Arch on an old 64bit Atom netbook. I got a nice hobby out of it, and liked it so much I put it on all my computers. If you have a knack for googling and enjoy reading high quality wiki pages that document far beyond the scope of the operating system, you'll probably enjoy it. It requires patience and some time investment, but it's no rocket science.

Re: Arch Linux pulls the plug on 32-bit

#98
post #41
post #24

It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances tha…

> I have an old ThinkPad T42 I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.

I completely agree with you on the pleasure of using such a well-crafted machine. From the keyboard, to the connectivity, to the overall build-quality and the way in which the designers thought out so many things so well, it makes me sad that that I cannot just swap out its socketed (yes socketed!) single-core processor for something more modern.

You make a good point- I too have been an open-source consumer. Yea I have filed a few bug reports, helped some people experience Linux or switch from IE6 to Firefox, but have not contributed much to these projects time- or money-wise. With things like the Linux kernel, that are suported by the likes of Red Hat and SUSE (which are in turn supported by big businesses), I am not too concerned about their survival. But after reading about the GPG maintainer and now the GNU Octave maintainer being forced to stop their their generous contributions, I realize perhaps I need to be doing more as a user for open-source things I care about being around in the future.

Re: Arch Linux pulls the plug on 32-bit

#99
post #46
post #24

It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances tha…

It's increadibly easy (although the computer will spend hours crunching) to make a boot disk for pretty much anything using buildroot. That honestly sounds like a better plan for underpowered hardware than expecting a major distro to support it.

This is definately something I need to look into. Not only would I be able to produce install images but also would have the chance to learn more about what goes into making that ISO file I take for granted. Thanks for posting!

Re: Arch Linux pulls the plug on 32-bit

#100

Earlier quoted context omitted.

What I wonder is why one would assume the python command would run python 2, instead of running python 1, assuming python 1 was a thing. By your logic, shouldn't python2, run python3 run python 3, etc. What I'm getting at, is we get used to things being a certain way, but often we're just following a convention that was set in place before we got onboard. Why do we still type "bash" instead of "bash4"?

The reason you would assume it is that, for a long time on every Linux distribution, there was a single way to run python2, and it was called 'python'. I'm not sure what you are getting at, this was just the way it was. You couldn't run python 2 any other way in some linux distros. The reason we don't need a 'bash4' is that, by and large, bash tried very hard to make sure they didn't break any bash3 scripts, so there…

[deleted]
Post reply on HN