i figured out the random hack which messed me up 12 years ago 2 days ago
/c:f20
and the buda bug is fixed on my system - took me 3 days strait to find it...
and the fuseblk hack took a while /c:2021

On Mon, Sep 20, 2021 at 8:39 AM Conor Williams <conor.willi...@gmail.com>
wrote:

> if it is a vfat filesystem it is ok....
>
> On Mon, Sep 20, 2021 at 8:37 AM Conor Williams <conor.willi...@gmail.com>
> wrote:
>
>> some of the fuseblk disc/k drivers/modules on peppermint which is a
>> flavour of ubuntu
>> are not even in the kernel space and there are mount.XYZ processes left
>> open which are
>> wide open to attack (with # fuser -p <PID>) /c09
>> for those chips tings
>>
>> On Mon, Sep 20, 2021 at 8:24 AM hiro <23h...@gmail.com> wrote:
>>
>>> i think the main reason people are willing to fall for the android
>>> platform is bec. there is no good long-term supply of updated phone
>>> hardware with backwards-compatible interfaces.
>>>
>>> a lot of qualcomm and mediatek chipsets are being built, but instead
>>> of documentation they only ship half-baked linux drivers, which are
>>> often not even mainlined.
>>>
>>> those linux drivers are already hard to make work on actual linux
>>> distributions, or even on android distributions.
>>>
>>> who wants to reverse-engineer the hardware over and over again based
>>> on such linux drivers...
>>>
>>> On 9/20/21, Ethan Gardener <eeke...@fastmail.fm> wrote:
>>> > tl;dr: forget inferno, port plan 9 to the pine phone.
>>> >
>>> > On Mon, Sep 20, 2021, at 6:43 AM, Dave Eckhardt wrote:
>>> >> > Anyone know if this project went anywhere?
>>> >> >
>>> >> > https://www.cs.cmu.edu/~412/lectures/L05_Purge_Proposal.pdf
>>> >
>>> > I had to laugh at one of the slides. Inferno running natively on "x86
>>> > supercomputer"? I think implementing multicore support would be a first
>>> > step, not to mention 64-bit! While it would be nice if those jobs were
>>> done,
>>> > they will take time and effort. Overall, if porting natively, I see
>>> little
>>> > sense in preferring Inferno to Plan 9, especially as Plan 9 already
>>> supports
>>> > 64-bit multicore.
>>> >
>>> >> Sadly, not.  One issue is that modern Android releases don't
>>> >> support 32-bit executables, and at the time that project was
>>> >> attempted Inferno was somewhat 32-bit (I haven't looked since).
>>> >
>>> > Recalling the issues Hellaphone had and the time it took, I'm of the
>>> opinion
>>> > that getting Inferno to work on any given phone's Linux kernel is
>>> hardly
>>> > more worthwhile than porting it directly to the hardware. The kernels
>>> have
>>> > undocumented interfaces.
>>> >
>>> > A current thread on OSdev (operating system development) forums is
>>> looking
>>> > at phones. It's a little rambly, but it reports on some encouraging
>>> things.
>>> > Lots of "baseband processors" (the phone-network communication
>>> subsystems)
>>> > have documented interfaces. There are at least 2 phones available now
>>> which
>>> > are fully open for operating system development: the PinePhone and the
>>> > Librem 5. (5 is the screen size.) Of the 2, the Pine Phone seems
>>> better, not
>>> > least because it can boot from the SD card; useful for testing.
>>> > https://forum.osdev.org/viewtopic.php?f=1&t=53251
>>> >
>>> > There's also the option of building your own phone out of components.
>>> The
>>> > thread has some info. I'm guessing most here would prefer a PinePhone.
>>> >
>>> >> But I think I saw some recent-ish Inferno-on-Android activity here:
>>> >>
>>> >>   https://github.com/bhgv/Inferno-OS-bhgv
>>> >
>>> > That's probably a good source of code. bhgv is a freelance programmer
>>> who
>>> > was very interested in Inferno and made several improvements including
>>> > Truetype fonts. The last I heard was he tried to find paid work
>>> involving
>>> > Inferno but couldn't, so he didn't have time to work on it.

------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-M080aad5bb3d8f05354a56fc5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to