**** BEGIN LOGGING AT Tue Dec 18 03:00:00 2018 Dec 18 03:07:37 Regarding my ccTLD question: apparently .au has it too: Dec 18 03:07:37 https://en.wikipedia.org/wiki/.au#Community_geographic_domain_names Dec 18 09:42:51 why uboot isnt installed on n900 by default? Dec 18 09:45:06 because it's not really "needed" by default I'd say Dec 18 09:45:08 (?) Dec 18 09:46:32 also, do i remember right that initrd part of nand is unused? Dec 18 09:59:11 Seems so. Mine's just full of 0xFFs Dec 18 09:59:18 "initfs" Dec 18 09:59:25 hmm Dec 18 09:59:38 seems like a perfect fit for kernel Dec 18 09:59:43 when uboot is installed Dec 18 10:01:07 u-boot can already fit alongside the stock 2.6.28 kernel within the 2 MiB kernel partition. Dec 18 10:01:21 even better Dec 18 10:02:08 Personally, I'd rather manage kernels within a filesystem. Dec 18 10:02:34 Use as little space for non-filesystem stuff as possible. Dec 18 10:03:02 Since once you're managing stuff within a filesystem, you don't have to mess around with provisioning particular amounts of space for particular things. Dec 18 10:03:19 There's no hard limit for the size of some kernel or some initramfs or something. Dec 18 10:05:34 and of course juggling things around on a file system is far safer than juggling things around within some flash partition. Dec 18 10:06:03 btw. for act dead non-broken fs is required or is there some minimal initrd glued to kernel? Dec 18 10:06:06 You start by writing the new kernel into a new file, instead of writing over an existing kernel and hoping your system doesn't lose power in the middle. Dec 18 10:06:35 KotCzarny: iirc non-broken fs is required Dec 18 10:06:39 well, initfs can hold 'safe' kernel or even kernel+minimal rescue Dec 18 10:06:45 ho hum Dec 18 10:06:53 yeah, that's silly Dec 18 10:07:07 kinda pointless to have separate kernel nand space then Dec 18 10:07:09 the whole act dead concept is silly tbh, but ... Dec 18 10:07:14 and typical "install-kernel" (or whatever it's called) scripts have been just renaming the old kernel to something like "vmlinuz.old" for ages, so you can still boot the old kernel if the new one doesn't function correctly. Dec 18 10:08:17 "installkernel"* Dec 18 10:08:43 darn, where is the maemo's summer of code to do all the nice things Dec 18 10:09:56 also with a filesystem if you're using flash, you should get the wear levelling implemented by the filesystem. Dec 18 10:10:42 whereas if you're writing over a particular mtd partition all the time, you're doing exactly what you're not meant to do with flash. Dec 18 10:11:12 yeah, nand is perfect for bootloader + kernel + rescueos (optional) Dec 18 10:11:53 and maybe some nonvolatile configuration data Dec 18 10:12:25 "non-volatile configuration" sounds like an oxymoron to me. Dec 18 10:12:35 there is runtime configuration too Dec 18 10:12:54 which is gathered/generated on boot Dec 18 10:15:02 to add to the wear levelling point: even if your mtd partition is not written frequently, simply withholding that space from something that actually does do proper wear levelling (such as ubifs) is counterproductive. Dec 18 10:15:35 Since the more space the filesystem has to play with, the more effective it will be able to perform wear levelling. Dec 18 10:15:59 That's why you're supposedly not meant to fill up SSDs. Dec 18 10:25:10 * Maxdamantus wonders when consumer MTD drives will become a thing. Dec 18 10:25:18 never? Dec 18 10:25:29 I wouldn't imagine it would be never. Dec 18 10:25:39 sdcards/ssds took the role Dec 18 10:25:40 It should be technically superior. Dec 18 10:25:54 technical superiority doesnt make it successful Dec 18 10:26:13 see slc vs anything else Dec 18 10:27:18 I'm not familiar with particular memory types, but aiui that's a matter of cost/benefit. Dec 18 10:28:06 with MTD drives, it's just a matter of having sufficiently useful software (filesystems), rather than hardware manufacturing techniques. Dec 18 10:28:47 atm we have SSDs that emulate block devices using flash, and then filesystems which rely on block devices. Dec 18 10:29:27 it would obviously be more efficient to have filesystems designed directly for flash, so the filesystem itself is performing wear levelling. Dec 18 10:30:10 No need to do periodic TRIMs or some other indication that blocks are unneeded. Dec 18 10:30:14 yet people are used to their filesystem, so ... Dec 18 10:30:38 Yes, filesystems are somewhat difficult to replace, but they do eventually get replaced. Dec 18 10:31:53 Maybe sometime someone will make an SSD that can be put into either a managed (block emulation) or unmanaged (MTD) mode. Dec 18 10:32:39 and maybe some future filesystem will be designed to work in either mode. Dec 18 10:33:24 note: Apple has only recently replaced HFS+ with AFS or whatever it's called as the default filesystem in their new OSes. Dec 18 10:33:54 APFS* Dec 18 10:34:49 so, ubifs for everyone Dec 18 10:36:42 yet, windoze crowd requires ntfs, which results in the need of firmware level wearlevelling Dec 18 10:54:45 ntfs will be replaced at some point. Dec 18 10:55:55 or even if it's not, I'm sure Microsoft has the capabilities to create an MTD variant of ntfs. Dec 18 10:56:11 or just move everything to 'cloud' Dec 18 10:57:05 I guess the proprietary drive towards MTD would probably be in phones. Dec 18 10:57:43 unless some big vendor starts seeing benefit of it, unlikely Dec 18 10:57:44 Since they're already relatively locked down in terms of filesystem access; iOS already switched to APFS without anyone really noticing. Dec 18 10:58:12 There's obviously benefit in it. It's just a matter of when people are going to put in the effort. Dec 18 10:58:17 apple crowd is rarely technical Dec 18 10:59:42 as long their magic boxes dont break, they wont notice even if their devices started shipping with soul eating daemons Dec 18 11:00:30 Whatever your thoughts are of Apple in particular, the phone market has obviously been tending towards things like greater computing efficiency: achieving more while using less power, so they can make their devices with smaller batteries. Dec 18 11:00:42 do they? Dec 18 11:00:46 more raw power, yes Dec 18 11:00:51 but efficency? Dec 18 11:00:57 * KotCzarny laughs heartily Dec 18 11:01:30 The software might not be more efficient, but the phones overall are. Dec 18 11:01:30 did you notice that every new os requires more ram/cpu than previous iteration? Dec 18 11:01:37 even taking into account the software. Dec 18 11:02:06 compare kitkat to nougat/oreo Dec 18 11:02:09 for starters Dec 18 11:02:47 bah, even updating google services is enough to kill 1gb ram device with slower storage Dec 18 11:03:03 Dunno what that comparison is meant to signify .. I prefer Oreo over Kit-kat .. never had Nougat. Dec 18 11:03:32 it just exemplifies that newer os revisions eat more resources Dec 18 11:03:35 often needlessly Dec 18 11:03:57 Right, like Wirth said. Dec 18 11:04:03 sure, you get more functionality here and there, but at the price of more resources eaten Dec 18 11:04:52 but which performs better at browsing typical webpages? Maemo/N900 or iOS 11/iPhone X (dunno if those are recent) Dec 18 11:05:12 given same ram amount available? Dec 18 11:05:13 :P Dec 18 11:05:21 No. Given the two options. Dec 18 11:05:29 apples to oranges Dec 18 11:05:57 we gen beefier devices, but with more hungry software that mitigates the gain Dec 18 11:06:04 (btw, Wirth as in Niklaus Wirth, or "Wirth's law") Dec 18 11:07:38 and beefier devices enable sloppy software Dec 18 11:08:59 we have hundred megabytes apps to process 20kb file into bitmap Dec 18 11:10:56 and most of that bitmap is filled with shit (ads) Dec 18 11:11:01 or useles junk Dec 18 11:13:31 Anyway, I completely agree that software is getting more bloated, but that doesn't *prevent* the fundamental parts of software improving. Dec 18 11:13:47 It does mean the improvements slow down though. Dec 18 11:14:53 we got tech, tech was new and shiny and tiny, lean and mean. then came the parasites and tech got boggled down Dec 18 11:15:06 There are still projects that are on the right path of making it possible to do things more efficiently. Dec 18 11:15:32 eg, being able to use something like Rust for creating efficient programs instead of C. Dec 18 11:16:08 thats because parasites didnt find out rust yet Dec 18 11:16:10 :) Dec 18 11:16:49 (not that either language prevents you from creating bloated software of course, but both allow you to create non-bloated software, and I think one allows you to do it in a more maintainable way) Dec 18 11:18:35 trust me, you can write bloat in any language :> Dec 18 11:27:20 they have different approaches between schools too. Some prefer efficient as for others it is "as long as it works". Dec 18 11:48:18 in some ways, the bloatedness of general software is at least partly what drives making other software more efficient, which is often still an improvement for handling software that is already good enough. Dec 18 11:48:50 and then we eat out all earth's resources and go back to stone age Dec 18 11:49:17 growth is nice, uncontrolled, rabid growth is just death race into the abyss Dec 18 11:50:06 now we have a bunch of regular joes having supercomputers at the reach of their hands, yet all they do is gossiping and looking at pictures/videos Dec 18 11:50:22 and producing trash, lots of trash Dec 18 11:52:26 Supposedly that's how capitalism is meant to produce technical improvements. Dec 18 11:53:03 and rot out at the same time Dec 18 11:53:19 Those "supercomputers" probably aren't profitable you can't convince the regular joes they need them. Dec 18 11:53:51 they DO need them, how would they gossip and look at pictures/videos otherwise? Dec 18 11:54:20 at a nice flat rate of xxx $$ **** ENDING LOGGING AT Wed Dec 19 03:00:01 2018