Linux 4.6-rc3 Kernel Released

[phoronix]

Phoronix: Linux 4.6-rc3 Kernel Released

Linus Torvalds has done his usual Sunday dance and released the Linux 4.6-rc3 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6-rc3-Released

[c117152]

"Meanwhile, you can grab the code via Git if you want to help out testing this new kernel version."

It is easier to download kernels from kernel.org and it is already available there:
https://www.kernel.org/

Horrible idea. That archive expands to about 10giga using the default 4096 block sizes and takes it's sweet time doing it. Since it's an RC release, you'd want to update it so not pulling with git is not even short-sighted, it's just silly.

[speculatrix]

In a pc, after unzipping the folder size is 623 MB and have 1GB size after compiling. It is a smart idea to have whole kernel in a new clean folder. partial builds can fail.

I always download the full tar.xz file and unpack it, apply any patches, copy in the config I used on the previous RC, set any additional kernel version flags in the Makefile, and then build.

[Azrael5]

OT Is there a way to update bioses bin rom files of different devices from linux by terminal?

[c117152]

In a pc, after unzipping the folder size is 623 MB and have 1GB size after compiling. It is a smart idea to have whole kernel in a new clean folder. partial builds can fail.

Not on disk. You're allocating per block not per file. A 1 byte file takes 4096bytes on disk on default partitioning schemes (all major distributions and operating systems). The addressing points per-block. And an EOF symbol marks the end of the file inside the block. It's like pointers and null termination in C strings.

If anything, compile servers are partitioned with 512bytes blocks for that exact reason.

And while linking it doubles over that 10g since all the linking files are made per source files.

I've recently compiled an entire Gentoo system. I had recorded ram usage over 8g, it ended up expanding to 70g, and while compiling it sometimes went over 100g..

[SystemCrasher]

It is easier to download kernels from kernel.org and it is already available there:

There are some little catches though:
- Git uses fairly efficient delta algo, so updating e.g. from RC2 to RC3 is fast and takes little network traffic either.
- Git allows one to try various versions fast.
- If bug hits you, "git bisect" would do the trick, spotting troublesome commit quite fast (compared to other methods).
- It could be useful to read at least "git log" to get idea what's going on.

Of course it really depends what one is up to. This would do for curious people who want to learn a bit more on how it works, why things happen the way they are, what's going on and what others would see tomorrow. Or year later. Or something.

[SystemCrasher]

If anything, compile servers are partitioned with 512bytes blocks for that exact reason.

I guess my Btrfs just does tail packing heck a lot in this case...

[bridgman]

Yes there are when using git. "Meanwhile, you can grab the code via Git if you want to help out testing this new kernel version.", that does not tell how to obtain linux kernel if you are not familiar with linux kernel git branch.

Tried responding to your PM about 4.6-rc3 but each attempt just sent out a blank post. No idea what's going on, let's see if this works...

[c117152]

So you are writing that Thunar lies when it calculates the size of a folder. Please do not explain how it is possible to copy 1GB file from 1GB usb memory stick to the ssd or vice versa and Thunar shows always 1GB.

Because your SSD and USB partitions are partitioned with 4096k blocks. It's the default on USB FAT as well.

Besides, he's not lying. Like already mentioned, he could be using a nonstandard block sub-allocation \ tail packing fs like btrfs. But those systems have computational and RAM overhead and don't deal well with power failures. And in the case of USB and SSDs, ssd_spread adds further overhead and complicates benchmarking.