| *** mavhc has quit IRC | 00:24 | |
| *** mavhc has joined #maemo | 00:27 | |
| *** mavhc has quit IRC | 00:44 | |
| *** mavhc has joined #maemo | 00:49 | |
| *** mavhc has quit IRC | 00:54 | |
| *** mavhc has joined #maemo | 01:01 | |
| *** xorly has quit IRC | 01:04 | |
| *** tdlnx has quit IRC | 01:16 | |
| *** florian has quit IRC | 01:20 | |
| *** mavhc has quit IRC | 02:04 | |
| *** mavhc has joined #maemo | 02:06 | |
| *** Kilroo has joined #maemo | 02:16 | |
| *** tdlnx has joined #maemo | 02:56 | |
| *** tm has quit IRC | 03:27 | |
| *** tm has joined #maemo | 03:31 | |
| brolin_empey | x86 computer hardware question (hurrian?): https://www.asus.com/2-in-1-PCs/ASUS-Transformer-Mini-T102HA/specifications/ Can this model of computer drive an external display at at least 3840×2160? I have been reading about Intel hardware on Wikipedia but cannot find a clear answer. Yes, I realise that having only 4 GiB of main memory sucks in practice in 2018. I do not have this model of computer, my friend does and I am curious to know if his computer is | 04:08 |
|---|---|---|
| brolin_empey | UHD-capable. | 04:08 |
| *** mavhc has quit IRC | 04:32 | |
| *** mavhc has joined #maemo | 04:37 | |
| *** mavhc has quit IRC | 04:42 | |
| *** mavhc has joined #maemo | 04:47 | |
| brolin_empey | Regarding my ccTLD question: apparently .au has it too: | 05:07 |
| brolin_empey | https://en.wikipedia.org/wiki/.au#Community_geographic_domain_names | 05:07 |
| *** pagurus has joined #maemo | 06:50 | |
| *** pagurus` has quit IRC | 06:52 | |
| *** tdlnx has quit IRC | 07:21 | |
| *** merlin1991 has quit IRC | 07:25 | |
| *** merlin1991 has joined #maemo | 07:25 | |
| *** Kilroo has quit IRC | 07:43 | |
| *** spiiroin has quit IRC | 07:48 | |
| *** mavhc has quit IRC | 07:51 | |
| *** mavhc has joined #maemo | 07:58 | |
| *** florian has joined #maemo | 08:06 | |
| *** florian has quit IRC | 08:11 | |
| *** mavhc has quit IRC | 08:12 | |
| *** mavhc has joined #maemo | 08:17 | |
| *** al3x_10m has quit IRC | 08:29 | |
| *** al3x_10m has joined #maemo | 08:31 | |
| *** mavhc has quit IRC | 08:33 | |
| *** mavhc has joined #maemo | 08:37 | |
| *** florian has joined #maemo | 08:39 | |
| *** florian has quit IRC | 08:45 | |
| *** mavhc has quit IRC | 08:47 | |
| *** mavhc has joined #maemo | 08:53 | |
| *** mavhc has quit IRC | 08:58 | |
| *** dafox has joined #maemo | 09:09 | |
| *** mavhc has joined #maemo | 09:15 | |
| *** spiiroin has joined #maemo | 09:16 | |
| *** spiiroin has quit IRC | 09:25 | |
| *** spiiroin has joined #maemo | 09:44 | |
| *** dafox has quit IRC | 09:54 | |
| *** Kabouik_ has joined #maemo | 10:31 | |
| *** Pali has joined #maemo | 10:58 | |
| *** mavhc has quit IRC | 11:06 | |
| *** mavhc has joined #maemo | 11:10 | |
| *** mavhc has quit IRC | 11:22 | |
| *** mavhc has joined #maemo | 11:31 | |
| *** florian has joined #maemo | 11:32 | |
| KotCzarny | why uboot isnt installed on n900 by default? | 11:42 |
| bencoh | because it's not really "needed" by default I'd say | 11:45 |
| bencoh | (?) | 11:45 |
| KotCzarny | also, do i remember right that initrd part of nand is unused? | 11:46 |
| Maxdamantus | Seems so. Mine's just full of 0xFFs | 11:59 |
| Maxdamantus | "initfs" | 11:59 |
| KotCzarny | hmm | 11:59 |
| KotCzarny | seems like a perfect fit for kernel | 11:59 |
| KotCzarny | when uboot is installed | 11:59 |
| Maxdamantus | u-boot can already fit alongside the stock 2.6.28 kernel within the 2 MiB kernel partition. | 12:01 |
| KotCzarny | even better | 12:01 |
| Maxdamantus | Personally, I'd rather manage kernels within a filesystem. | 12:02 |
| Maxdamantus | Use as little space for non-filesystem stuff as possible. | 12:02 |
| Maxdamantus | 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. | 12:03 |
| Maxdamantus | There's no hard limit for the size of some kernel or some initramfs or something. | 12:03 |
| Maxdamantus | and of course juggling things around on a file system is far safer than juggling things around within some flash partition. | 12:05 |
| KotCzarny | btw. for act dead non-broken fs is required or is there some minimal initrd glued to kernel? | 12:06 |
| Maxdamantus | 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. | 12:06 |
| bencoh | KotCzarny: iirc non-broken fs is required | 12:06 |
| KotCzarny | well, initfs can hold 'safe' kernel or even kernel+minimal rescue | 12:06 |
| KotCzarny | ho hum | 12:06 |
| bencoh | yeah, that's silly | 12:06 |
| KotCzarny | kinda pointless to have separate kernel nand space then | 12:07 |
| bencoh | the whole act dead concept is silly tbh, but ... | 12:07 |
| Maxdamantus | 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. | 12:07 |
| Maxdamantus | "installkernel"* | 12:08 |
| KotCzarny | darn, where is the maemo's summer of code to do all the nice things | 12:08 |
| Maxdamantus | also with a filesystem if you're using flash, you should get the wear levelling implemented by the filesystem. | 12:09 |
| Maxdamantus | 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. | 12:10 |
| KotCzarny | yeah, nand is perfect for bootloader + kernel + rescueos (optional) | 12:11 |
| KotCzarny | and maybe some nonvolatile configuration data | 12:11 |
| Maxdamantus | "non-volatile configuration" sounds like an oxymoron to me. | 12:12 |
| KotCzarny | there is runtime configuration too | 12:12 |
| KotCzarny | which is gathered/generated on boot | 12:12 |
| Maxdamantus | 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. | 12:15 |
| Maxdamantus | Since the more space the filesystem has to play with, the more effective it will be able to perform wear levelling. | 12:15 |
| Maxdamantus | That's why you're supposedly not meant to fill up SSDs. | 12:15 |
| * Maxdamantus wonders when consumer MTD drives will become a thing. | 12:25 | |
| KotCzarny | never? | 12:25 |
| Maxdamantus | I wouldn't imagine it would be never. | 12:25 |
| KotCzarny | sdcards/ssds took the role | 12:25 |
| Maxdamantus | It should be technically superior. | 12:25 |
| KotCzarny | technical superiority doesnt make it successful | 12:25 |
| KotCzarny | see slc vs anything else | 12:26 |
| Maxdamantus | I'm not familiar with particular memory types, but aiui that's a matter of cost/benefit. | 12:27 |
| Maxdamantus | with MTD drives, it's just a matter of having sufficiently useful software (filesystems), rather than hardware manufacturing techniques. | 12:28 |
| *** eMHa has quit IRC | 12:28 | |
| Maxdamantus | atm we have SSDs that emulate block devices using flash, and then filesystems which rely on block devices. | 12:28 |
| Maxdamantus | it would obviously be more efficient to have filesystems designed directly for flash, so the filesystem itself is performing wear levelling. | 12:29 |
| Maxdamantus | No need to do periodic TRIMs or some other indication that blocks are unneeded. | 12:30 |
| bencoh | yet people are used to their <insert favourite> filesystem, so ... | 12:30 |
| Maxdamantus | Yes, filesystems are somewhat difficult to replace, but they do eventually get replaced. | 12:30 |
| Maxdamantus | Maybe sometime someone will make an SSD that can be put into either a managed (block emulation) or unmanaged (MTD) mode. | 12:31 |
| Maxdamantus | and maybe some future filesystem will be designed to work in either mode. | 12:32 |
| Maxdamantus | note: Apple has only recently replaced HFS+ with AFS or whatever it's called as the default filesystem in their new OSes. | 12:33 |
| Maxdamantus | APFS* | 12:33 |
| KotCzarny | so, ubifs for everyone | 12:34 |
| KotCzarny | yet, windoze crowd requires ntfs, which results in the need of firmware level wearlevelling | 12:36 |
| *** xorly has joined #maemo | 12:47 | |
| Maxdamantus | ntfs will be replaced at some point. | 12:54 |
| Maxdamantus | or even if it's not, I'm sure Microsoft has the capabilities to create an MTD variant of ntfs. | 12:55 |
| KotCzarny | or just move everything to 'cloud' | 12:56 |
| Maxdamantus | I guess the proprietary drive towards MTD would probably be in phones. | 12:57 |
| KotCzarny | unless some big vendor starts seeing benefit of it, unlikely | 12:57 |
| Maxdamantus | Since they're already relatively locked down in terms of filesystem access; iOS already switched to APFS without anyone really noticing. | 12:57 |
| Maxdamantus | There's obviously benefit in it. It's just a matter of when people are going to put in the effort. | 12:58 |
| KotCzarny | apple crowd is rarely technical | 12:58 |
| KotCzarny | as long their magic boxes dont break, they wont notice even if their devices started shipping with soul eating daemons | 12:59 |
| Maxdamantus | 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. | 13:00 |
| KotCzarny | do they? | 13:00 |
| KotCzarny | more raw power, yes | 13:00 |
| KotCzarny | but efficency? | 13:00 |
| * KotCzarny laughs heartily | 13:00 | |
| Maxdamantus | The software might not be more efficient, but the phones overall are. | 13:01 |
| KotCzarny | did you notice that every new os requires more ram/cpu than previous iteration? | 13:01 |
| Maxdamantus | even taking into account the software. | 13:01 |
| KotCzarny | compare kitkat to nougat/oreo | 13:02 |
| KotCzarny | for starters | 13:02 |
| KotCzarny | bah, even updating google services is enough to kill 1gb ram device with slower storage | 13:02 |
| Maxdamantus | Dunno what that comparison is meant to signify .. I prefer Oreo over Kit-kat .. never had Nougat. | 13:03 |
| KotCzarny | it just exemplifies that newer os revisions eat more resources | 13:03 |
| KotCzarny | often needlessly | 13:03 |
| Maxdamantus | Right, like Wirth said. | 13:03 |
| KotCzarny | sure, you get more functionality here and there, but at the price of more resources eaten | 13:04 |
| Maxdamantus | but which performs better at browsing typical webpages? Maemo/N900 or iOS 11/iPhone X (dunno if those are recent) | 13:04 |
| KotCzarny | given same ram amount available? | 13:05 |
| KotCzarny | :P | 13:05 |
| Maxdamantus | No. Given the two options. | 13:05 |
| KotCzarny | apples to oranges | 13:05 |
| KotCzarny | we gen beefier devices, but with more hungry software that mitigates the gain | 13:05 |
| Maxdamantus | (btw, Wirth as in Niklaus Wirth, or "Wirth's law") | 13:06 |
| KotCzarny | and beefier devices enable sloppy software | 13:07 |
| KotCzarny | we have hundred megabytes apps to process 20kb file into bitmap | 13:08 |
| KotCzarny | and most of that bitmap is filled with shit (ads) | 13:10 |
| *** eMHa has joined #maemo | 13:11 | |
| KotCzarny | or useles junk | 13:11 |
| Maxdamantus | Anyway, I completely agree that software is getting more bloated, but that doesn't *prevent* the fundamental parts of software improving. | 13:13 |
| Maxdamantus | It does mean the improvements slow down though. | 13:13 |
| KotCzarny | we got tech, tech was new and shiny and tiny, lean and mean. then came the parasites and tech got boggled down | 13:14 |
| Maxdamantus | There are still projects that are on the right path of making it possible to do things more efficiently. | 13:15 |
| Maxdamantus | eg, being able to use something like Rust for creating efficient programs instead of C. | 13:15 |
| KotCzarny | thats because parasites didnt find out rust yet | 13:16 |
| KotCzarny | :) | 13:16 |
| Maxdamantus | (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) | 13:16 |
| KotCzarny | trust me, you can write bloat in any language :> | 13:18 |
| Vajb | they have different approaches between schools too. Some prefer efficient as for others it is "as long as it works". | 13:27 |
| *** florian_kc has joined #maemo | 13:43 | |
| Maxdamantus | 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. | 13:48 |
| KotCzarny | and then we eat out all earth's resources and go back to stone age | 13:48 |
| KotCzarny | growth is nice, uncontrolled, rabid growth is just death race into the abyss | 13:49 |
| KotCzarny | 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 | 13:50 |
| KotCzarny | and producing trash, lots of trash | 13:50 |
| Maxdamantus | Supposedly that's how capitalism is meant to produce technical improvements. | 13:52 |
| KotCzarny | and rot out at the same time | 13:53 |
| Maxdamantus | Those "supercomputers" probably aren't profitable you can't convince the regular joes they need them. | 13:53 |
| KotCzarny | they DO need them, how would they gossip and look at pictures/videos otherwise? | 13:53 |
| KotCzarny | at a nice flat rate of xxx $$ | 13:54 |
| *** EgS has quit IRC | 14:18 | |
| *** al3x_10m has quit IRC | 14:19 | |
| *** al3x_10m has joined #maemo | 14:19 | |
| *** mavhc has quit IRC | 15:06 | |
| *** mavhc has joined #maemo | 15:12 | |
| *** mavhc has quit IRC | 15:19 | |
| *** mavhc has joined #maemo | 15:24 | |
| *** spiiroin has quit IRC | 15:44 | |
| *** EgS has joined #maemo | 15:51 | |
| *** spiiroin has joined #maemo | 16:13 | |
| *** mavhc has quit IRC | 16:21 | |
| *** xorly has quit IRC | 16:27 | |
| *** mavhc has joined #maemo | 16:28 | |
| *** Pali has quit IRC | 17:02 | |
| *** Pali has joined #maemo | 17:15 | |
| *** spiiroin has quit IRC | 17:23 | |
| *** spiiroin has joined #maemo | 17:44 | |
| *** spiiroin has quit IRC | 17:49 | |
| *** florian_kc has quit IRC | 17:55 | |
| *** spiiroin has joined #maemo | 18:06 | |
| *** Pali has quit IRC | 18:19 | |
| *** Pali has joined #maemo | 18:22 | |
| *** Pali has quit IRC | 18:22 | |
| *** Pali has joined #maemo | 18:28 | |
| *** Pali has quit IRC | 18:36 | |
| *** Vajb has quit IRC | 18:45 | |
| *** dafox has joined #maemo | 18:53 | |
| *** Pali has joined #maemo | 18:54 | |
| *** florian has quit IRC | 19:00 | |
| *** tdlnx has joined #maemo | 19:36 | |
| *** dafox has quit IRC | 19:39 | |
| *** mavhc has quit IRC | 19:40 | |
| *** mavhc has joined #maemo | 19:44 | |
| *** mavhc has quit IRC | 20:04 | |
| *** mavhc has joined #maemo | 20:08 | |
| *** mavhc has quit IRC | 20:14 | |
| *** mavhc has joined #maemo | 20:21 | |
| *** mavhc has quit IRC | 21:06 | |
| *** mavhc has joined #maemo | 21:08 | |
| *** eMHa has quit IRC | 21:19 | |
| *** Vajb has joined #maemo | 21:26 | |
| *** eMHa has joined #maemo | 21:52 | |
| *** florian_kc has joined #maemo | 22:15 | |
| *** mavhc has quit IRC | 22:50 | |
| *** mavhc has joined #maemo | 22:55 | |
| *** xes has quit IRC | 23:14 | |
| *** xes has joined #maemo | 23:14 | |
| *** shentey has joined #maemo | 23:31 | |
| *** shentey has quit IRC | 23:47 | |
| *** Kabouik_ has quit IRC | 23:55 | |
| *** shentey has joined #maemo | 23:58 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!