Slashdot Mirror

Thanx for the link - it looks like there is some performance impact on the ARM64s. Noted here: http://lists.infradead.org/pip...

Never think what you are using is perfect.

I've been using CeroWrt (https://www.bufferbloat.net/projects/cerowrt/wiki/ - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.

Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my daughter for being able to watch Netflix without me yelling).

With the 12Mbps link, it doesn't seem to be the ingress traffic that causes issues, but the egress traffic (at times, I upload large data sets). Without shaping the outbound traffic, I can see round-trip times in excess of 2 seconds which is just a bit excessive. ;-)

I recently installed LEDE (https://lede-project.org/) (an OpenWrt (https://openwrt.org/) fork) on a spare router (the same model as the CeroWrt router - WNDR3800) and it is obvious that the software continues to improve.

It appears that LEDE may be approaching its first stable release (https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552). If you have a spare router that is supported by LEDE, please consider installing a current build and report any issues found.

If you would like to learn more, here are a few random links to get you started:

• Explaining RRUL Charts (https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Chart_Explanation/)
• The Cerowrt-devel Mailing List Archives (https://lists.bufferbloat.net/pipermail/cerowrt-devel/)
• The Lede-dev Mailing List Archives (http://lists.infradead.org/pipermail/lede-dev/)
• Does LEDE support my router? (https://lede-project.org/supported_devices)
• The Make Wi-Fi Fast Wiki (https://www.bufferbloat.net/projects/make-wifi-fast/wiki/)
• The Make-wifi-fast Mailing List Archives (https://lists.bufferbloat.net/pipermail/make-wifi-fast/)
• Possible OpenWrt and LEDE merge (https://www.google.com/search?q=OpenWrt+LEDE+merge)
• All of Dave's Patreon posts (https://www.patreon.com/dtaht/posts)

I feel that the work that Dave (and everyone else that is involved) is so important that I send a few coins his way every month via Patreon. Here's his most recent update: "Where your donations go" (https://www.patreon.com/posts/where-your-go-7564906).

Dave, a belated Merry Christmas to you and I'm looking forward to a New Year where all of the efforts to tame bufferbloat and make WiFi fast benefit everyone.

If you want to use Linux on this platform in "RAID" mode with the supported BIOS, the source code to enable it is part of this patch series from an Intel developer: http://lists.infradead.org/pip.... It's not pretty, but it sounds like that's just how the hardware works.

Has anyone actually used the pine?

They are just beginning to go out to backers now. Android is working, Linux is more or less working, and from what I can tell, the mainline kernel support for the Allwinner A64 is nearing completion. Note that this will explicitly not include video drivers in the kernel. You will still need a binary blob Mali driver just like now, until the Lima project gets something really working. A64 mainline kernel support was a major bullet point for PineA64, and it was supposed to be finished right around now. At least it's still being developed, and not abandoned.

That only happens without a flash translation layer (FTL), for example when you want to write to a non-empty page of a memory technology devices (MTDs) in Linux (as can be found in many embedded systems). You can read about the capabilities of (raw) flash devices and how the UBI system works on top of MTDs here. The FTLs in SSDs are proprietary, so there's no easy way to know how current flash controllers implement the FTL.

I don't think there's any parcticular need for a special package if you already have fast broadband. Most of the decent free TV is on iPlayer, which covers all the BBC channels and now has content from the major free to view commercial rivals:

http://www.bbc.co.uk/iplayer/

You might also want to check out the ITV Player, 4od and Demand 5 sites (I rarely bother).

You can grab BBC (only) programmes from iPlayer with get_iplayer, which generates standard mp4 files you can play anywhere (finally a use for that Apple TV!):

http://www.infradead.org/get_iplayer/html/get_iplayer.html

Some US TV sites can be accessed by methods like this (or get a VPN):

http://xtremisreaction.wordpress.com/2011/01/08/how-to-watch-the-daily-show-with-jon-stewart-in-the-uk/

http://xtremisreaction.wordpress.com/2013/01/05/how-to-watch-hulu-and-us-television-in-the-uk/

Because BIOS routines are still written for real mode.

Ew. That seems like something that should be fixed.

Beyond that, all modern commercial BIOS are a dreadful mess filled with binary patches and cruft.

That's really not a good reason, considering there is a modern, open source BIOS -- Coreboot, formerly LinuxBIOS. I see no reason vendors couldn't adopt that, and start extending it.

Usually it's a disaster even if it only has to support a single architecture. I'd hate to see one meant to run on any OS and any CPU.

nVidia claims something like 90-95% of the code in their video drivers is shared between all platforms.

The drive controller, etc are a decentish place to hide their valuable IPee

Bullshit. People have been "hiding" that IP in software, too. If there's a reason for people to reverse-engineer it, they will, anyway.

and maintain a well defined and well understood interface that's already supported everywhere.

Well, mostly everywhere. But I can see the appeal, there. It is, however, an interface with some shortcomings...

On the other hand, that implies the kernel interfaces should be similarly well defined and well understood. How difficult is it to present a Volume under Windows, or a block device under Linux? Consider that FUSE interfaces already exist for Linux and OS X -- surely a POSIX filesystem API is more difficult than a block API?

I'd have somewhat less trouble with this idea if it was possible to bypass that abstraction layer and use the raw device, for filesystems and OSes that can take full advantage of it. But it's presented as this SATA black box, to which we're slowly starting to add features that were there already on more primitive devices.

You can get an IDE controller for practically any platform. I don't think you can even buy a mainboard that doesn't have one.

I'm pretty sure mine doesn't. Most SSDs, including mine, are SATA.

Meanwhile, it's not like you could get rid of glue logic anyway.

Fair enough. However, I think this goes beyond the amount of glue logic we want.

I may have made this analogy before, but it's a bit like hardware RAID. Some slight performance gain that just becomes irrelevant in a generation or two, and older/dumber OSes can pretend it's just a single hard drive. Downsides are, you're paying for extra, unnecessary hardware, the logic in the RAID controller is probably inferior, and the RAID layer really can't talk to the filesystem layer, preventing some of the cooler features of ZFS.

Speaking of which, you don't want the CPU twiddling it's thumbs waiting for that state machine to complete an erase operation (very slow). Issuing a TRIM command is fire and forget.

No, but is there a reason the CPU has to? I suppose that depends on the interface used...

I should point out that chroot can be trivially broken out of.

True, but that's largely because people never tried to make it into a jail, and instead focused on virtual machines.

Of course, I'm guessing that you can only really break that jail as root, correct?

Jail is tougher, but it's easy to accidentally leave a back door.

The same could be said of any system, including virtualization.

Really, I think virtualization is a similarly brutal hack, that may be justified by the amount of work it saves, but really, we should just do the work.

Example: Virtual machines can be migrated from one physical machine to another, without anything inside the VM even noticing. However, LinuxPMI already does this to some extent with individual processes. It's a hard problem, but not impossible.

And an obvious

It's even worse than just that.

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_ftl

"For example, it is known that some vendors optimize their FTL devices for FAT..."

Basically we won't really have full use of our hardware until Windows is forced to evolve.

The same problem led to the creation of WEP. Just because Windows' in-kernel encryption is as useful as piglatin, hardware and drivers have to pick up the slack. Don't say it's because of embedded devices - they've been powerful enough to run Blowfish since before Blowfish itself was specified.

Before you get all excited about running UBIFS on your USB drive, take note: UBI is not for consumer flash media. These devices already incorporate hardware to hide their flash nature so they look like a plain old block device to your OS. UBI is for pure flash devices that directly expose the quirks and distinct characteristics of the underlying media.

So what kind of flash hardware is this for? Embedded devices, apparently. But maybe as flash storage becomes more common, more devices will support raw access?

It's basically just like SRS (which you need to use if you use SPF) except using it on your own outgoing mail instead of forwarded mail. And by using it, SPF becomes utterly worthless.

The idea is that you use a unique MAIL FROM: for all legit mail you sent, and simply reject all bounce messages that isn't going to these addresses.

See here and here: here for more details.

Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.

Wikipedia on xD cards
Instructions to fit an xD card to a Mattel Juicebox
A comment on LWN from Wookey, who knows a lot about flash
xD card pinout

My best advice is to ask people on the linux-mtd mailing list for specific details.

Flash drives do not write FAT32 out to the flash.

"Until recently, the common approach to using Flash memory technology in embedded devices has been to use a pseudo-filesystem on the flash chips to emulate a standard block device and provide wear levelling, and to use a normal file system on top of that emulated block device."

Taken from http://linux-mtd.infradead.org/~dwmw2/jffs2.pdf.

Oh, and it's a very bad idea to put swap in a Flash device, unless you want to wear out the sectors pretty quickly and render the chip useless.

This is actually possible to do in linux 2.4. Believe me, I am an expert on this kind of thing, as my situation is similar -- the Intel pentium chipsets only cache the lower 64MB of RAM, so on systems with more RAM you would like to tell linux to use the lower RAM preferentially.

The secret is the slram.o module in the MTD section of the linux kernel. See here for the full scoop. This module doesn't solve everything; in particular, linux doesn't disk cache as effectively when slow ram is in use. You'll just have to see for yourself whether it's worth it or not.

A quick check on Google popped up the following links:

(LILO CRC error...)
http://www.linuxgazette.com/issue50/tag/24.html
http://brenner.chemietechnik.uni-dortmund.de/doc/s db/en/html/kfr_50.html

(Grub cannot fit selected item into memory)
http://www.gnu.org/manual/grub-0.92/html_node/Stag e2-errors.html
http://mm.ilug-bom.org.in/pipermail/linuxers/Week- of-Mon-20020729/005620.html
http://lists.infradead.org/pipermail/linux-mtd/200 0-March/000346.html

Based on those links, I'd be chasing down something taking some of your low memory away from you so that it doesn't boot right. Keep in mind, it may still be an ailing HD as intimated in the LILO links. As for the bootloaders being ready, they are- you've got a special case that's causing you problems and many, many others don't seem to have your issues with them. I can't speak of Red Hat's support since I've not used their distribution in a while- so you may have a beef there.

Actually, there's a filesystem designed for this very application. It's called JFFS, or Journaling Flash Filesystem. The original development for the filesystem was done by Axis Communications, but it has since migrated to the kernel proper under the term JFFS2. You can probably follow discussions regarding this filesystem and the kernel API at the Memory Technology Devices site. Check out the mailing list archives and/or subscribe to linux-mtd from the aforementioned site.

If it's similar to the handheld Linux's like Familiar, they probably use JFFS2, the journaling flash file system. It does compression and intelligently minimizes writes to flash devices. Another one is CRAMFS, a popular choice for embedded 2.4 systems .

Regards,
Reid

Linux has a chance to take the Palm/PDA world by storm if we can only get our collective butts in gear!

The following projects are critical and need our support -

Microwindows/Nanogui

uLinux

LinuxCE

flash memory drivers

And the existing Linux7k project.

Let's get the ball rolling!