Slackware 14.2 Released, Still Systemd-Free (slackware.com) 179
sombragris writes: Slackware, the oldest GNU/Linux distribution still in active maintenance, was released just minutes ago. Slackware is noted for being the most Unix-like of all Linux distributions. While sporting kernel 4.4.14 and GCC 5.3, other goodies include Perl 5.22.2, Python 2.7.11, Ruby 2.2.5, Subversion 1.9.4, git-2.9.0, mercurial-3.8.2, KDE 4.14.21 (KDE 4.14.3 with kdelibs-4.14.21) Xfce 4.12.1... and no systemd!
According to the ChangeLog: "The long development cycle (the Linux community has lately been living in "interesting times," as they say) is finally behind us, and we're proud to announce the release of Slackware 14.2. The new release brings many updates and modern tools, has switched from udev to eudev (no systemd), and adds well over a hundred new packages to the system. Thanks to the team, the upstream developers, the dedicated Slackware community, and everyone else who pitched in to help make this release a reality." Grab the ISOs at a mirror near you. Enjoy! The torrents page can be found here.
According to the ChangeLog: "The long development cycle (the Linux community has lately been living in "interesting times," as they say) is finally behind us, and we're proud to announce the release of Slackware 14.2. The new release brings many updates and modern tools, has switched from udev to eudev (no systemd), and adds well over a hundred new packages to the system. Thanks to the team, the upstream developers, the dedicated Slackware community, and everyone else who pitched in to help make this release a reality." Grab the ISOs at a mirror near you. Enjoy! The torrents page can be found here.
There's a very cool live version also (Score:5, Informative)
Now with Plasma 5! [slackbook.org] You can plug the stick into any machine, and it runs perfectly right out of the box, two monitors, weird audio, doesn't matter, everything works.
Once you go Slack, you never look back!
Re:There's a very cool live version also (Score:5, Interesting)
I started with Slackware back around 1994-ish, enjoyed feeding the endless floppy disks during the install and even "released the magic smoke" on a monitor due to some booboos in the modelines setting up XFree86. After some years on Redhat/Fedora, a friend, back around 2007, introduced me to Ubuntu and I've been on that since, and am currently on 14.04LTS. However, I have a sneaking suspicion I'm not gonna be moving to 16.04 due to the infestation of systemd into the Ubuntu infrastructure... I've tried the previous version of Slackware 14.1 both on my laptop and in vbox, and I got a feeling I'm gonna move to this new release of Slackware as it gets closer to EOL of 14.04.....
Re: (Score:2)
Same story, but wound up confused the first time through because I somehow landed myself an a.out kernel for an ELF distribution. Ah, well; EFNet #linux...
I do wonder what Slackware's biggest downfall is these days. IIRC, it was package management or the general lack thereof, previously. I've got a laptop with FreeBSD *ahem* PC-BSD on it that wants a different flavor of *NIX, I might try throwing it on there...
Re:There's a very cool live version also (Score:5, Interesting)
"Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished."
Although I think he should really consider runit over systemd, because Void Linux uses it and it boots really fast. It's probably the fastest booting binary distribution. Of course a customized Gentoo install could probably beat it. IMO Void sort of embodies that same ideals that Slackware does (i.e. a simple and effective system that puts the administrator in control rather than the corporation) but it uses modern tools that do that and it's rolling release, while Slackware is more focused stability.
Re: (Score:3)
But, you know: With any less-than-5-year-old machine that wasn't junk to begin with, a few gigabytes of cheap RAM, and any sort of proper SSD, every OS seems to boot like a rocketship (driver loading timeouts and specific waitstats notwithstanding).
I mean, the laptop I spoke of before is a stout Dell Precision kit I got for about $200, used, about a year ago. It boots PC-BSD with ZFS in a bunch of seconds that I can't be bothered with trying to clock with a recent mSATA SSD.
For all of the arguments for/ag
Re:There's a very cool live version also (Score:4, Funny)
Re: (Score:2)
Real Linux users only boot a machine once, so the boot speed hardly matters.
TFTFY.
Anyone using an SSD is not going to be worried about boot times in any case.
Re: (Score:2)
sysvinit is a services manager. People have hacked it so it's a daemon manager that runs shell scripts. Those shell scripts then manage daemons.
Look at it yourself - chances are, getty and the like are not spawned from a shell script, but from init directly. And w
Re:There's a very cool live version also (Score:5, Insightful)
shell scripts are great. They are flexible, powerful, transparent, easily changeable, debug-able ... With systemd you have a blackbox and have to learn magic keywords. It is like windows - for idiots - not for hackers. Yes, the shell script based system sometimes was a mess. But the solution is to clean the scripts up not to replace them...
Re: (Score:2)
> Then again, I hate managing the S/K file pairs
Slackware doesn't use those. They're available as an optional add-on, if needed for compatibility with something you installed. Personally, I've never had any need for them in many years on Slack.
Re: (Score:2)
Now with Plasma 5! [slackbook.org] You can plug the stick into any machine, and it runs perfectly right out of the box, two monitors, weird audio, doesn't matter, everything works.
Once you go Slack, you never look back!
That sounds good and I'll definitely give it a spin. One question; can you install Slackware from the live media? On the Slackware site, under Install Help, step 3 says "You need to have a diskette with a root filesystem and the setup program in order to install Slackware Linux". Really? I haven't owned a machine with a diskette drive in years. Have I missed some way of installing it from a bootable CD/DVD/USB device?
Re: (Score:2)
Slackware has a USB version of the "floppy" in the distro that you dd to a stick to boot from, which is just used for the install. The live version I use is not from Slackware (Slackware (Pat) itself does not produce live systems) per se, but the entire setup is drawn from official Slackware, Slackbuild, and KDE mirrors (for plasma 5, there is an unmodified Slackware iso made to run live also). I haven't tried an install from it. I'm happy running it live as is. I just back up the home directory to save my personal changes.
Thanks! I'll check it out.
Fantastic news! (Score:4)
One of the very first Linux distribution is still alive and kicking (without systemd!).
Great work Patrick & crew, I'll make sure I'll order a DVD soon!
Re: (Score:2)
How did you manage to post an edh? Seriously?
Slackware is awesome (Score:3)
Great news (Score:2)
Sincerely, great news.
Now, if it would just remove X11/Xorg completely and rely only in Wayland, it would be my dream distro :-)
(Dreaming is allowed, ain't it?)
PS: I grew writting the X11 config file manually in my long-dead first PC and grew really hating X11 (like when as child something makes you sick and, as adult, you eat it but don't like it).
Re: (Score:2)
Re:Great news (Score:5, Informative)
Couldn't be simpler:
open /etc/inittab
# These are the default runlevels in Slackware:
# 0 = halt
# 1 = single user mode
# 2 = unused (but configured the same as runlevel 3)
# 3 = multiuser mode (default Slackware runlevel)
# 4 = X11 with KDM/GDM/XDM (session managers)
# 5 = unused (but configured the same as runlevel 3)
# 6 = reboot
# Default runlevel. (Do not set to 0 or 6)
id:4:initdefault:
Re: (Score:2)
Except that it pretty much every Unix and Linux since the 90s, the 2-3-4-5 runlevels have been:
0: Shutdown for halt
1: Single user
2: No networking
3: Headless system with networking
4: Undefined, for the admin's discretion
5: Headed system (gui, graphical)
6: Shutdown for reboot
If I enter "init 2", I expect the network services to stop.
If I enter "init 5", I expect the graphical system (usually X11 with a chooser) to start.
Different UNIX/Linux init subsystems handle this differently, but the 1/2/3/5 runle
Re: (Score:2)
Sorry no. Debian and derivatives have always take the tack that runlevels are user/admin defined, and unless you change things everything will start in runlevel 2.
Re: (Score:2)
I enter "init 5", I expect the graphical system (usually X11 with a chooser) to start.
Different UNIX/Linux init subsystems handle this differently, but the 1/2/3/5 runlevels can generally be counted on to be the same.
Breaking this is introducing incompatibilities for the sake of being different.
Why? If you have to edit inittab, it shows you the meaning of each runlevel just above the "Default runlevel" line as the (grand)parent post shows. Not exactly "breaking things to introduce incompatibilities".
Re:Great news (Score:4)
It's worth noting that the only people with a clue about what Wayland actually does that are pushing Wayland are ones working in the phone and tablet spaces. Nice for them - sucks for the rest of us yet people keep on trying to shove it down our throats.
Re: (Score:3)
Absolutely. And even for the phone and tablet space is big mistake to switch away from X. Where could be more useful to move windows freely between devices than with mobile devices....
Can I get my Yggdrasil please? (Score:5, Funny)
/ this is my lawn
Re: Can I get my Yggdrasil please? (Score:2)
Yggdrasil? Graybeard alert! :)
Re: (Score:2)
Yggdrasil? Graybeard alert! :)
Ayup. Actually used to have the very first Red Hat distro, we switched to it in a heartbeat because it was so much easier to update running systems.
This would be '94-'96
Re: (Score:2)
Nay, 'tis a compliment. It's not like that grey doesn't show up by itself after a decade or three. Oh, wait...
Who cares? -- Former slack user here (Score:5, Interesting)
I used to love Slackware. Timely releases, no dependency hell, and very simple package management.
There was never a problem with their package management...simple tgz files with an install script onsite, and there were multiple tiny 3rd party utils to manage versions and uninstalls. It really was great for being able to have a minimal system, know exactly what was on it, and just be able to understand it perfectly.
A couple of years ago, this changed. It was now not only recommended to do a full install, but support was not required UNLESS people did a full install, at least by most of the community.
This is frustrating. Slackware started out as being the most unix like Linux. Something it has clearly abandoned...when installing mplayer REQUIRES installing Samba, just in case you need to play a file across an SMB share.
They are not targeting the same audience, and instead are targeting the audience of distros like Ubuntu...except they won't ever win. I don't know what niche they serve anymore, aside from brand loyalists.
Arch seemed like a good replacement, but it is bleeding edge only. So, I've gone to the BSD side. I would love for Slackware to do a course correction, but that seems unlikely.
Re: (Score:2)
Re: (Score:2)
I can understand them not wanting to support every random configuration. I develop for a hobby, not do tech support. Unless you are paying for support them in afraid the further you get from the recommend config the more on your own you are.
It sucks but my time if valuable too. I try to help, but there are limits.
Having said that, the mplayer example you give does indeed suck.
Awesome and so... (Score:2)
python 2.7.11? (Score:3)
Its like they are not even trying. Python 3.5 is perfectly okay.
Good news! (Score:2)
Although I've been using it less and less for the past couple of years, Slackware remains my favorite Linux distribution. Ohter distributions simply became easier to install and maintain over the years. However, I'm considering moving back to Slackware, because that vile concoction called systemd is starting to infest every Linux distribution that is out there, with the exception of some of the more esoteric distributions. And truth be told, IMHO Slackware is the only "real" Linux distribution left.
The firs
It will be a cold day in... (Score:2, Insightful)
Re:Systemd-free (Score:5, Informative)
Systemd isn't mentioned anywhere in the release notes or the website...
ChangeLog: http://www.slackware.com/chang... [slackware.com]
Re: (Score:2)
It looks like the real story here is they had to change from udev to eudev in order to keep it that way.
Re:Systemd-free (Score:5, Informative)
Eudev is more or less a fork of udev before it was absorbed by systemd. In my dealings with it, it works exactly like how udev worked before the systemd developers hijacked the project so, I would imagine it was a trivial but necessary change for Slackware.
It will be interesting to see how long Slackware can resist systemd. Even venerable projects like LFS (Linux From Scratch) seem to be leaning towards its adoption. They still provide the non-systemd book as the default but, looking at the mailing lists, I'm not sure how long it will remain the default.
Re: (Score:3)
Only if you think long waits on the order of "never" would qualify as interesting. It's my understanding that many of people who happen to have significant influence in the direction that Slackware takes are quite opposed to the idea of systemd's inclusion in Slackware, so if one wants an otherwise "slackware-like" system that uses systemd, it will have to be a fork.
Re:Systemd-free (Score:5, Interesting)
They might be opposed to systemd on a moral level but, they may not be able to avoid it on a technical level. As systemd absorbs more and more things, and more things start to depend on systemd, it's a simple problem of manpower: Unless your distro is run by a multi-billion dollar company that has the resources to undo the damage caused by systemd, you may have no choice but to adopt it.
It's interesting to think of systemd in terms of The Cathedral and Bazaar. RedHat built a really nice stall in the middle of the bazaar. Initially everyone loved it and it was very healthy for the bazaar. Then one day they looked around and realized that they owned considerable interests in all the surrounding stalls in the bazaar and decided, "You know what? We should just build a cathedral right here in the middle of the bazaar and bring all these stalls inside".
Re: (Score:2, Interesting)
Re: (Score:2)
Forks require maintenance, though. If virtually every large project in the ecosystem has to be forked, the manpower required to support them all will be prohibitive.
Re:Systemd-free (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
KDE and Gnome do not become irretrievably dependent on systemd. They become dependent on a feature it provides or the API it exposes, like cgroups which is part of the Linux Kernel. There's no reason someone can't write something else to implement that functionality. Based on the number of people who say systemd is doing it wrong here on Slashdot, expect 5+ alternatives to every single API systemd exposes.
Re: (Score:2)
Re: (Score:3, Insightful)
If people care about systemd then the forks will be maintained. If they don't then I guess it turns out that the community isn't nearly as concerned about systemd as they have claimed.
Re: (Score:2)
There may be plenty of people who care, but they might constitute the minority of the overall community, and therefore incapable of maintaining forks of the entire ecosystem of that larger community.
Or it might be that too many of those people who care, don't have the skills and/or the time necessary to maintain such forks.
Re: (Score:2)
Or it might be, that they people who care are simple not yet organized enough and it just takes some time until this happens....
Re: (Score:2)
but they might constitute the minority of the overall community
Precisely what I was saying. Now the Slashdot prediction was that Linux will cease to exist, RedHat won't have a single user, and the singularity approaches and will kill us all. Reality may not turn out that way.
Linux has always been community built and community driven underneath. There are technical reasons why some distributions are going certain directions, but these very distributions spawned out of an interested community base.
So again, if this is the situation it was made out to be the forks will be
Re: (Score:2)
not yet
I think we're on different timelines here. The topic is about future declines due to maintenance, not a question as to whether alternative projects are getting off the ground .... which they are.
Re: (Score:3)
Personally, I always picture it liuke this [radiotimes.com]
Re:Systemd-free (Score:4, Insightful)
But I will definitely give slack another look. I miss my "just works" Linux of old.
Re: (Score:2)
Re: (Score:2)
As systemd absorbs more and more things, and more things start to depend on systemd, it's a simple problem of manpower: Unless your distro is run by a multi-billion dollar company that has the resources to undo the damage caused by systemd, you may have no choice but to adopt it.
I don't think it's likely to be a problem, most systemd components are being replaced by non-systemd components (like ConsoleKit2, or elogind). No one seems really excited to depend heavily on systemd because of its limitations, so I expect systemd might remain nothing more than an init system into the future. It is ok as an init system, and doesn't prevent people from using other init systems, so I don't see a huge problem there.
Re:Systemd-free (Score:5, Insightful)
Re: (Score:2)
That's why things like persistent user processes in the background (about chapter three in most scripting books) is just not something he sees as being something that should exist.
Interesting that he created a whole new API for this functionality then.
Oh wait, unless it exists in the exact single implementation which you are used to then it doesn't really exist is that how it works?
Re: (Score:2)
No problem, we just have to rewrite a pile of scripts with his incredibly verbose new syntax, watch them run and silently fail, then just keep on changing bits and pieces until they work, for the moment, via the moving target black box of systemd.
Or we can just use old systems that work until Lennart sees the next shiny
Re:Systemd-free (Score:4, Insightful)
He says that: 1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system). 2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.
So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).
bogus argument - this so-called security risk is also there when the user is logged in - you cannot really make security contingent on a user being logged in, because logged in means zip - user can be logged in a system for weeks w/o doing anything ..in reality LP redefines what it means to have a user account, and what it means to be logged in, arbitrarily limiting the user (and this *is* windows think), I mean next thing he figures out its a good idea for security to log user out at midnight, eventually figuring out he needs positive id checking user's ass is continuesly behind the terminal..)
Re: (Score:2)
Read his blog. You can see the mindset at work there. He just does not get this messy *nix thing and wants to "fix" Redhat's platform to make it like the "modern" MSDOS with a GUI under the control of a single entity that he is used to.
Re: (Score:3)
they may not be able to avoid it on a technical level. As systemd absorbs more and more things, and more things start to depend on systemd
Things don't depend on systemd. Things depend on functionality provided by a program that no other program provides. If systemd absorbs a critical part of the system (e.g. udev) then you can simply fork it and move on. If systemd provides some functionality on the other hand then it is up to the Linux community to do what it used to do best, rather than bitch and moan, get coding and provide an alternative to the required functionality.
There's no technical reason that everything will ultimately end up depen
Re: (Score:2)
Exactly, they will avoid it until avoiding entails more effort than including it.
There is an old interview on LQ that ta
Re: (Score:2, Insightful)
Indeed. And the good news is that there are now two larger distros that can can maintain eudev. Unless the systemd-cabal manages to get the kernel dependent on systemd (and that would be really bad for compatibility and security, so I doubt it is going to ever happen), it is actually not that hard to do a systemd-free (i.e. classical stable and reliable) Linux distro. You just have to maintain what is already there and works well, an idea that the systemd fanatics do not understand, of course. And applicati
Re: (Score:2)
Re: (Score:2, Funny)
EUdev? Is there something for the UK too?
Re: (Score:2)
Okay I'll have to eat some humble pie. I did a search on the links for systemd and nothing came up. I probably misspelt it.
Oh well modded appropriately :-)
Re:systemd rocks! (Score:5, Funny)
Definitely. Whenever I find deadlocks and race conditions in my code, I just sprinkle the code with sleep(1). PROBLEM SOLVED!
Re:systemd rocks! (Score:4, Informative)
lol
The first test in our automated testing process (which reviews every pull request before it's merged) is to test for "sleep"... we completely disallow it to be used... ever!
How did it get this way? Well, I'm sad to say that it was actually my fault. I have a habit when I'm debugging particularly tricky MPI code (we do massively parallel scientific simulation) to use "sleep(pid)" where "pid" is the "processor ID" or "rank" of the current MPI process. I use it to "serialize" print statements so they don't clobber each other. There are definitely other ways to achieve the same thing... but this is quick and dirty while I'm developing.
Unfortunately... I accidentally checked in code with these a couple of times. Running in serial (1 processor) it only causes a 1 second slowdown... but if you're running on 10,000 processors... well... you're going to be waiting a while!
Since it happened twice, "sleep" got the perma-ban by our devs (to save themselves from me!).
Anyway - a little off-topic... let me try to pull it back on topic. Slack was the first distro I ever loaded back in the 90s. I downloaded it to several (20ish?) 3.5" disks at my job (after school job doing tech support at a local ISP)... got them all home and tried to install it and guess what? Yep. One of those disks was corrupted. Took two more tries before I was able to get it going... but my mind was permanently BLOWN once I got it working :-)
Re: (Score:2, Interesting)
Well, I'm sad to say that it was actually my fault. I have a habit when I'm debugging particularly tricky MPI code (we do massively parallel scientific simulation) to use "sleep(pid)" where "pid" is the "processor ID" or "rank" of the current MPI process.
See, your problem was that you should have used "sleep(pid % 10)". That way when you release your debug code, performance is just "not quite right" instead of "broken in an unfathomable way". Then, when you realize you've released your debug code, you can quietly go in, take it out, bless a new build and humbly accept your accolades for your engineering prowess.
Slack was the first distro I ever loaded back in the 90s.
I imagine that a large portion of slashdot readers cut their teeth on slack. Slack was probably the most popular user distro when slashdot was fo
Re: (Score:2)
I got the CD (v3.0) glued to a magazine cover, and used it to download the images for a newer release.
By the time software was customarily distributed on CDROM, typical modems were 28.8kbps. 2400 BAUD was late 80s/early 90s. Slackware 3.0, the first version released on CD was in `95. Most stores only sold 14.4 and 28.8 modems in `95.
Downloading v3.5 still took 3 days.
Re: (Score:2)
Re: (Score:2)
Hah! It had a similar effect... but not on purpose!
Thanks for the good link!
Re: (Score:2)
Anyway - a little off-topic... let me try to pull it back on topic. Slack was the first distro I ever loaded back in the 90s. I downloaded it to several (20ish?) 3.5" disks at my job (after school job doing tech support at a local ISP)... got them all home and tried to install it and guess what? Yep. One of those disks was corrupted. Took two more tries before I was able to get it going... but my mind was permanently BLOWN once I got it working :-)
That happened to all of us I think. At least I haven't met anyone that it didn't happen to. You sat there copying your floppies (the cheapest available, since you were poor) at uni and when trying to install back home number 23 was always broken. So back to school in the rain. Twice! :-)
Re: (Score:2)
No doubt on the "cheapest available"... used to buy ENORMOUS stacks of them... 50 or 100 at a time or whatever.
They were crazy unreliable... but hey, what else is a kid supposed to do? :-)
BTW: The same thing went for burnable CDs once they came out. I had HUGE spindles of crappy CDs. Always important to run the "verification" part of the burn process ;-)
The analog these days is USB sticks and SD cards... but I'm older and wiser now and employ just a few that are higher end...
Re: (Score:2)
You laugh because you know it's true.
Re:systemd rocks! (Score:5, Insightful)
It's also kind of suspicious that the only service manager that D-Bus talks to when it comes to D-Bus activation is systemd, leading to a malformed state in every other system that doesn't use systemd, because it starts services outside the service manager. That gentle push.
Re:systemd rocks! (Score:5, Insightful)
If the people behind systemd had any actual Unix-development skills, that is exactly what they would have done. Instead we have a monster that tries to assimilate everything. Huge egos often coincide with small skills. This is a nice example.
Re: (Score:2)
Probably more that in a server you can be systemd-free with current Debian without much trouble (well and some non-functional systemd-cruft lying around). I expect Devuan will become fully functional pretty fast once that changes. If it does.
But nice fail to understand what is going on on your side. Fits the picture.
Re:Wow, Slackware is that much behind? (Score:4, Interesting)
Re: (Score:2)
Oldest, sure... but behind? least developed? Where are you getting those ideas from?
The changelog, and the previous changelog. Ancient versions of software, really really slow release cycles. To anyone used to standard distribution development behind and least developed describes it perfectly. The fact that Slackware released a version seems to have surprised many people.
Re: Wow, Slackware is that much behind? (Score:2)
One of the reasons I stick with Slack is that unlike Debian I don't have to use ancient software versions with back ported patches. Who are these people you speak of? Do they have Internet or reading disabilities? distrowatch.com/dwres.php?firstlist=slackware&secondlist=ubuntu&firstversions=1&resource=compare-packages&secondversions=1
Re: (Score:2)
conservative (RHEL, Centos, SuSE) and the bleeding edge (Arch, Fedora, OpenSUSE).
Although I wished they would have dropped the ESR version of Firefox.
Re:Wow, Slackware is that much behind? (Score:4, Informative)
Slackware -does- use the standard init system. Everyone -else- has been making crazy things up and doing their own thing.
Re: (Score:3)
They're way ahead of where many will be in 10 years when they're all stripping out systemd.
Re: (Score:2)
Re: (Score:2)
A completely new fork of Linux, called something else obviously, and that remains systemd-free...
Now we're getting dreamy! I'd love to see that day. And the ones leaving would love it too, right? Everybody wins!
Now, just teach people who hate systemd how to do all that technical stuff that is required, and we can live in that world. Maybe figure out how to build an IDE as a first-person shooter? I don't think just getting chanting RTFM at the rubber ducky is going to motivate these users to acquire the skills. People who do that eventually end up at the web pages that explain the technical reasons for
Re: (Score:2)
Because Python 3 doesn't work (at least not with existing code). Python 3 is for all intents and purposes an entirely different language and why would any dev dump an existing/working codebase, experience and paradigms just because someone didn't think all that well about what a programming language needs in the past?
Re: (Score:2)
It is not that bad. 2to3 already does a pretty decent job of converting. Some manual work required after that, but a "different language" is just hyperbole.
Re: (Score:2)
For the purposes of running random downloaded code, they are two different languages, in a sense that neither is a subset of the other, and so they're not compatible in either direction.
Re: (Score:2)
And so we have both of them, for the time being. I do not see a big problem.
Re: (Score:2)
There are subsets of C and Java (C++, ObjC, Kotlin, Scala) that are older than 8 years and also 'largely semantics and tools that facilitate code conversion' yet we still have plenty of code being written in plain old C or Java.
A programming language is primarily semantics, changing the semantics implicates that it is a different language regardless of the similarity, if it were the same language, things would largely still work (perhaps with deprecation warnings).
Re: (Score:3)
I wondered the same thing. I guess if all you ever deal with is ASCII, Python 2 is ok. But 3 makes it a lot easier to deal with non-ASCII Unicode, and as a linguist I have to deal with that every day. (Although I'll admit it's still not easy--I still feel like I have to stand on my head to open a Unicode file, even in 3.)
Re: (Score:2)
Python 2 had full Unicode support, too. You had to be explicit about it (u'' literals etc), but it was there.
Re: (Score:2)
I know, I used it for years that way. But it's easier in 3. And it wasn't that hard to switch over; most of the work was done by 2to3.py I did still have to fiddle with open(), though; it seems like opening a file in utf8 could have been made easier.
Re: (Score:2)
It seems reasonable to default to current locale encoding for files (and stdin/out/err), since it's what most other apps will do.
Re: (Score:2)
I can see the logic behind that, but it means that a program that works on one computer will not work the same on another computer, even when (IIRC) the input is coming from (or going to) a pipe, which means it has no necessary relation to whatever encoding someone's shell is set to. We've been bitten by that several times.
What I'm getting at is that I have to write code like this:
strMainFSTOut = codecs.getwriter('utf-8')(sys.stdout.buffer)
when it seems like
Re: (Score:2)
It's the same problem for pipes - if you are passing text around, the program on the other side of the pipe has to agree with you on the encoding, and the de facto standard for that is to use locale.
BTW, did you know that you can change the encoding of stdin/out/err specifically using PYTHONIOENCODING environment variable? Works for both 2.7 and 3.x, too.
Re: (Score:2)
But I have to make that assumption regardless of how file open() works; for me, it's just a question of how much code I have to write, whether I need to import the codecs library and call its functions, or whether that's done under the hood.
I know about the PYTHONIOENCODING variable, but I want to make my program self-contained. Not every computer I run on will have PYTHONIOENCODING set.
Most UNIX like? (Score:2)
...that would be introduced in a major version change.
Aka. The most aged.
UNIX systems also have a migration over time unfortunately for the most part UNIX was beat out by Linux. However MacOS X is a UNIX system. And Solaris was Turning to be more Linux like.
What we see as Real UNIX like is just out nostalgia for the old systems ignoring the modern trade offs that has happened to deal with today's computing demands.
Re: (Score:2)
Wait, what? You run Slackware on your watch?
http://instantrimshot.com/ [instantrimshot.com]
Re: (Score:2)
1995? I'm pretty sure I used linux before 1995 and I'm 100% sure I used slackware as distribution. Must be more like 1992 or 1993.