[SOLVED] Backtracking to sanity

PrinceCruise · 04-15-2013, 05:54 AM

Quote:

Originally Posted by ruario

There are still many nice improvements in what is being lined up as 14.1. Many could benefit from these now, rather than waiting for 15 at some significantly later date.
New releases are a revenue stream for our BDFL, so waiting too long could punish him financially.

I totally agree with that, ruario.

- I'm totally unaware of the awesomeness of -current as I don't use it. The reason is I live in an area where I 'theoretically' have superfast 3G internet but in reality I don't, so I stick to the -stable one and keep updating whenever I get hold of a fast connection.
And on the other hand, things are working so smooth with fully updated 14.0 and awesome packages from Alien and SBo, I thought it would be worth waiting a bit longer for another release like this.

- I totally understand the second point. Soon enough, I too would be able to pay my humble donations to the most awesome Linux OS ever.

However, I too would defer to the wisdom of Pat and the crew.

Regards.

sanjioh · 04-15-2013, 05:55 AM

Quote:

Originally Posted by ruario

Two things:

There are still many nice improvements in what is being lined up as 14.1. Many could benefit from these now, rather than waiting for 15 at some significantly later date.
New releases are a revenue stream for our BDFL, so waiting too long could punish him financially.

As long as the quality is good (and you can see by his thought process that this is exactly what he intends), I see no problem with having smaller but more frequent updates, like the proposed 14.1. So yeah, I am in favour of making the proposed changes.

I entirely quote ruario on this, so count +1 on this opinion

tronayne · 04-15-2013, 06:52 AM

Quote:

Originally Posted by Erik_FL

You will probably find that you can't use the Intel compiler. Some of the "fiddling and twiddling" is to add extensions to the ANSI C language. Source for some Linux software requires those extensions to the C language. Hopefully Linus has resisted the temptation to use non-ANSI language extensions in the kernel and discouraged that for other people doing kernel development.

One that has bitten me a few times is the "?" operator. Syntax like this is not ANSI C compatible.

Code:

x = y ? : z;

The GNU compiler accepts the above syntax and it is equivalent to this in ANSI C.

Code:

x = y ? y : z;

I am always leery of language extensions designed to save typing. They generally give up error detection in favor of convenience. What if the programmer just forgot to type in the variable name that they really wanted to use and didn't want "y"?

I also notice that a lot of C programs are really C++ in disguise. The programs are intended to be C but will only compile using C++ because they have C++ syntax in some places. Compiler developers should resist the urge to "fix" C compilers to allow using C++ syntax.

Yeah, I've noticed all that sort of nonsense too. Whenever I'm writing something and the synapses go down a blind alley, my first point of reference in K&R 2nd ed. I don't recall ever having voluntarily used "? :" conditional expressions -- even the example in on p. 51 of the book looks goofy (yeah, it works, but somebody may have to look at your code some day and not know what the heck you're doing; if - else if - else, I think is clearer and thus more desirable. But that's just me.

Dennis chose to include break, too (for the folks coming from FORTRAN, I think). Never, ever, used one of those either.

Sigh.

brianL · 04-16-2013, 03:40 AM

Quote:

Originally Posted by volkerdi

I'd rather be targeting the next release as 14.1 and a stable, evolutionary update to 14.0 rather than a 15.0 that's churned out before the components have really have a chance to mature upstream. There's enough of that happening elsewhere, and in my humble opinion it doesn't need to happen here.

Sounds good to me. Agree with what's been said by other Slackers, too.

perbh · 04-16-2013, 08:03 AM

+1 for ruario (and Pat for that matter)

I have been a distro-hoe for too long - with arch I ended up updating virtually every day *chuckles*.
Coming back to Slackware its ever so refreshing - and I'm still using vanilla 14.0 - and ... its more 'modern' (if I may use that word - maybe 'recent' is a better one) than almost any previous versions (notwithstanding - I still have a server somewhere running 10.1 with a 2.4.27 (or is it 28 or 29?) kernel. It's been going for years and years - only interrupted by power-outages).
Also, most of my machines use the intel graphics and the few that don't, use nouveau - so no problems (I don't do games).
Which reminds me - I do have one with an ATI on the mobo *shivers* - the only distro I have found that will run it is vanilla 14.0!! Everything else go belly-up! (mind you, 13.37 would probably work as well, ain't tried it)

So yes please - stability first and foremost.

<edit> just checked on my old server - its a 'custom' 2.4.30-kernel where everything not needed is taken out (or as modules). It's a dual cpu running at some 366 MHz and has 384 MB of memory ... wow!
Guess its time to put it out of its misery ...
</edit>

dugan · 04-16-2013, 11:21 AM

For the record, the fact that Pat is willing to make decisions like this is why I'm using Slackware and not Arch.

1337_powerslacker · 04-16-2013, 11:23 AM

Quote:

Originally Posted by dugan

For the record, the fact that Pat is willing to make decisions like this is why I'm using Slackware and not Arch.

+1 on that. Couldn't have said it better myself.

colorpurple21859 · 04-16-2013, 02:45 PM

I like Woodsman approach

Quote:

You have done this in the past: how about 3.4 for the release and 3.8 in /extra?

I have a laptop with amd hd6700m hybrid graphics that had overheating problems that the 3.8 kernel fixed.

JohnB316 · 04-17-2013, 10:14 AM

I'm using slack64-current on a rig I built myself as my daily OS. I've compiled the Nvidia binary blob beta version using GCC 4.8.0 and the 3.8.4 kernel. There were no problems with compiling the Nvidia binary blob on my rig. The only issues I've run into are compiling Chromium from source using GCC 4.8.0 and compiling the MATE mixer from source with GCC 4.8.0 (I'm able to compile all the other pieces of MATE, and I'm using it as my daily desktop environment over KDE, XFCE or LXDE). Other than those two issues, slack64-current is working very well for me as is. I would have no objections to Pat reverting some things if it makes slack-current all the better for all its users.

Cheers!

Spinlock · 04-17-2013, 11:34 PM

My only gripe at the moment is that VirtualBox refuses to compile with GCC 4.8, so I'd be thrilled to go back on that (I haven't had a working VirtualBox in months.)

I definitely won't worry if those packages head backwards. I would like to continue to see a more recent KDE, though - 4.10x has had better performance here.

volkerdi · 04-18-2013, 01:15 AM

Quote:

Originally Posted by Spinlock

My only gripe at the moment is that VirtualBox refuses to compile with GCC 3.8, so I'd be thrilled to go back on that (I haven't had a working VirtualBox in months.)

No problem here with the recently released VirtualBox 4.2.12 and gcc-4.8.0. There was an asm issue with the VirtualBox kernel modules and gcc-4.8.0-pre, but that patch went in before the final 4.8.0 was released. Might want to make sure you have the latest VirtualBox, try it, and report back.

DrHouse · 04-18-2013, 05:12 AM

I installed -current releases to Samsung N150 netbook and Desktop PC (G31-ESL2 .v2; Intel Dual Core 2.93 Ghz; 4GB DDR2; NVIDIA GT 630) they're works great

1. 3.8.4 have not any critical bugs for me,
only message ACPI BIOS Bug: Warning: Incorrect checksum in table [TAMG] - 0xBF, should be 0xBE (20121018/tbutils-324)
2. Some packages, like grub2 won't build with GCC-4.8.0
3. New 1.14.0 Xorg runs great too.

tuxbg · 04-18-2013, 05:54 AM

Quote:

Originally Posted by DrHouse

I installed -current releases to Samsung N150 netbook and Desktop PC (G31-ESL2 .v2; Intel Dual Core 2.93 Ghz; 4GB DDR2; NVIDIA GT 630) they're works great

1. 3.8.4 have not any critical bugs for me,
only message ACPI BIOS Bug: Warning: Incorrect checksum in table [TAMG] - 0xBF, should be 0xBE (20121018/tbutils-324)
2. Some packages, like grub2 won't build with GCC-4.8.0
3. New 1.14.0 Xorg runs great too.

You need this in SlackBuild to compile grub2 with gcc-4.8

Code:

sed -i -e '/gets is a/d' grub-core/gnulib/stdio.in.h

And this patch for flex

Code:

---
 grub-core/script/yylex.l |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/grub-core/script/yylex.l b/grub-core/script/yylex.l
index f6a39c5..f4ff2bd 100644
--- a/grub-core/script/yylex.l
+++ b/grub-core/script/yylex.l
@@ -29,6 +29,8 @@
 #pragma GCC diagnostic ignored "-Wmissing-prototypes"
 #pragma GCC diagnostic ignored "-Wmissing-declarations"
 #pragma GCC diagnostic ignored "-Wunsafe-loop-optimizations"
+#pragma GCC diagnostic ignored "-Wsign-compare"
+#pragma GCC diagnostic ignored "-Wunused-function"
 
 #define yyfree    grub_lexer_yyfree
 #define yyalloc   grub_lexer_yyalloc
--

DrHouse · 04-18-2013, 09:18 AM

Thank you!

y0g1 · 04-18-2013, 09:57 PM

Hello,
In my opinion, we should stay with most recent software version as possible when talking about slackware-current.
If there are bugs - they shoud be noticed upstream to software developers. Maybe they will fix them.
From these 3 core components I would agree to downgrade kernel (if it helps). It is easy to change it so if someone needs 3.8.X version it may recompile just one package.
I would stick with gcc-4.8.X. Each new version of other software will support it, so there should not to be more problems with it.
I have no opinion about Xorg, but from these 3 components it is easy to change version of kernel and gcc.
With Xorg, we must change many more packages, so I would stay witch current version. In previous versions of Xorg I noticed many problems witch touchpanel drivers.
If there are plans for next Slackware release - it make sens to switch back to stabe software versions. But if we have some time for testing, lets raport bugs we found and wait for fix.