Android is currently more or less a disaster in terms of updates and security fixes. To people used to "apt-get upgrade" and "unattended-upgrades", the situation is laughable - you buy a phone and you know from the start you will get (maybe) one update to the next version of the OS - if you're lucky. After that, you're left in eternal limbo - an easy target for exploits and all sorts of malware.
Android Treble may finally help with this disaster - but for now, those of you that can, should try LineageOS.
Thanks - that is indeed my handle nowadays. Though when I opened my Slashdot account back in my Uni days I went with 'ttsiod' - our mainframe (I believe it was called "Cyber"?) could only accommodate a maximum of 6 or 7 letter login names:-)
- is always accessible even though I have a dynamic IP (via free DNS providers)
- has a Lighttpd web server so I can share things with the world
- has an Exim mail server, so I can receive mail over (E)SMTP, store it in my house, and read it over SSH/mutt
- can be SSH-ed into, which allows me to Wake-On-LAN my main desktop, whenever I need access to it
r- uns long running web downloads (e.g. wget/rtorrent) from within screen-ed sessions, and shares them over Samba to my house-bound devices (e.g. watch movies from my Android tablet)
- SSH is exposed over sslh in my HTTPS port (bypassing several firewall limitations in various places - cough, work, cough)
etc.
It also required soldering to access the board's serial port - all in all, very useful tinkering:-)
Based on @ShanghaiBill's solution, I wrote a solver and simulation in Python (that also fixes ShanghaiBill's buggy pinning of "him.rock" to 0.5 - the player could in theory, choose to play rock at more than 50% probability).
Use Pypy for speedy execution - I uploaded the code to GitHub:
https://github.com/ttsiodras/R...
My Speccy was the gateway to a life of IT (I ended up becoming a software engineer, and part-owner of a startup). Will always feel grateful to the designers of the 8-bit micros that started all this...
Oh, and I still remember my first hack - dissassembling JetPac and finding the POKE that gave me infinite lives. Now *that* was fun:-)
HeapCheck, Electric fence, Dmalloc and all memory debuggers in general, are basically replacing the allocation functions in the executable with their own version.
The "extra" stuff that the patent proposes, is a BOOLEAN flag, that HeapCheck functions would check upon entry (at runtime) - therefore allowing the developer to control (ON/OFF) the machinery at runtime. For example, the substitute allocation function can check a registry setting, to decide whether the functionality is on or off, and a separate utility GUI can toggle this registry setting on/off (I believe Microsoft's PageHeap has something exactly like that).
So tell me, do you REALLY consider this addendum - a boolean flag, for pitty's sake - enough "innovation", to warrant the term "invention"? Patentable "invention"?
You are actually arguing... that adding a boolean flag, controlled at runtime - a BOOLEAN flag! - constitutes enough... innovation, to make this... a completely new invention, worthy of patenting?
That is, if the allocation function checks e.g. a registry setting upon entry, and a GUI application simply sets this registry entry to True/False.... then suddenly the contribution is so enormous, to warrant the label of "new invention"?
I am a coder, not a lawyer - and from reading the patent's claims, I can see only one thing that was not in HeapCheck, but which DID exist in Electric Fence: the ability to enable heap checks at runtime, without recompilation. Electric Fence allowed one to do that via LD_PRELOAD, so I am sorry, but I stand by what I said - I can see nothing in there that didn't exist in either Efence or my HeapCheck.
I only take an issue with your last paragraph - I certainly didn't leave the code in a graveyard, I released it with an open source license, so that anyone could use it and make his life a bit better. The fact that 10 years later, someone else has now patented the ideas in Electric Fence and HeapCheck, and can now sue me and everyone else using it, is what got me mad (hence the "trolls" comment).
Use ZFS if you are in OpenSolaris/FreeBSD land, or use a Reed-Solomon tool - a GPL implementation of mine was Slashdotted 2 years ago, here: http://users.softlab.ntua.gr/~ttsiod/rsbep.html
I also use rsync and OpenSolaris/ZFS to keep daily backups.
BUT - important:
If the content is made of big files that change slightly each day (e.g. VMWARE/VirtualBox disk images), make sure you also use "--inplace" when you do the rsync, so that you take advantage of the copy-on-write semantics of ZFS. For example, I am using rsync to back up a VMWARE server to an OpenSolaris/ZFS fileserver, where the virtual disks are huge "vmdk" files - in the order of 10GB each. These huge files change only a little each day (less than 1%) - rsync would indeed realize this and only copy over the network the parts that changed, but it would store completely new copies in the backup server for each day! (I am assuming here that you would ZFS-snapshot each day). If instead you use the --inplace option of rsync, rsync will not only send the blocks that changed, but it will also only write the blocks that changed - thus, your ZFS will be able to host many years' worth of daily snapshots of these "vmdk", a truly marvelous thing, if you think about it...
> I'd wager that this guy has never worked on huge projects
And you would be wrong.
I've worked in very large projects (in the Telecom industry), and am currently coding specialized C/C++ code generators for the European Space Agency (the kind that actually generate the static, speedy, typesafe code that is appropriate for many projects). I know what you are talking about, and I never implied that Python is the way to go for all kinds of problems. My site has just as much C++ stuff as it does Python (e.g. my realtime 3D renderers) - even x86 SSE asm!
What I am trying to show people is that there are many kinds of problems where scripting languages are not only adequate, but in fact the best way to go about... Google uses and advocates Python a lot, and Eric Raymond (esr) explains why a lot better than I ever could (Why Python?).
In this day and age, developing speed and code clarity is just as important (if not more) as execution speed. Try Python and you'll know what I mean, when I refer to developing speed... And as for code clarity, the world is moving towards dynamic and type-infering languages (Ocaml, F#) for a reason...
(Re-post: for some reason the response I sent some hours ago didn't appear)
No, actually there is no bug.
If you read the contents of the 'show.pl' script, you'll see that it adapts to a
missing '' by reading from the next volume - the next recxxx...bz2.
As for the title, what you describe can't happen because of a fortunate
side-effect: when compressing, bzip2 (as other compressors) look for previous
appearances of a token (in this case, '<title>') and code a reference to it
(instead of the full text) to save space. Since "text" and "title" appear
all the time in these blocks (at least once for each article), they will NOT be
split - they will be encoded as "references", and therefore, what you describe
shouldn't happen (I hope:-)
No, actually there is no bug.
If you read the contents of the 'show.pl' script, you'll see that it
adapts to a missing '' by reading from the next volume - the next recxxx...bz2.
As for the title, what you describe can't happen because of a fortunate side-effect:
when compressing, bzip2 (as other compressors) look for previous appearances of a
token (in this case, '<title>') and code a reference to it (instead of the full
text) to save space.
So you see - no bugs:-)
Slashdot Mirror
Android Treble may finally help with this disaster - but for now, those of you that can, should try LineageOS.
Thanks - that is indeed my handle nowadays. Though when I opened my Slashdot account back in my Uni days I went with 'ttsiod' - our mainframe (I believe it was called "Cyber"?) could only accommodate a maximum of 6 or 7 letter login names :-)
http://users.softlab.ntua.gr/~...
The server...
It also required soldering to access the board's serial port - all in all, very useful tinkering :-)
Based on @ShanghaiBill's solution, I wrote a solver and simulation in Python (that also fixes ShanghaiBill's buggy pinning of "him.rock" to 0.5 - the player could in theory, choose to play rock at more than 50% probability). Use Pypy for speedy execution - I uploaded the code to GitHub: https://github.com/ttsiodras/R...
Oh, and I still remember my first hack - dissassembling JetPac and finding the POKE that gave me infinite lives. Now *that* was fun :-)
The "extra" stuff that the patent proposes, is a BOOLEAN flag, that HeapCheck functions would check upon entry (at runtime) - therefore allowing the developer to control (ON/OFF) the machinery at runtime. For example, the substitute allocation function can check a registry setting, to decide whether the functionality is on or off, and a separate utility GUI can toggle this registry setting on/off (I believe Microsoft's PageHeap has something exactly like that).
So tell me, do you REALLY consider this addendum - a boolean flag, for pitty's sake - enough "innovation", to warrant the term "invention"? Patentable "invention"?
You are actually arguing... that adding a boolean flag, controlled at runtime - a BOOLEAN flag! - constitutes enough... innovation, to make this... a completely new invention, worthy of patenting?
That is, if the allocation function checks e.g. a registry setting upon entry, and a GUI application simply sets this registry entry to True/False.... then suddenly the contribution is so enormous, to warrant the label of "new invention"?
Really? Are you serious?
I am a coder, not a lawyer - and from reading the patent's claims, I can see only one thing that was not in HeapCheck, but which DID exist in Electric Fence: the ability to enable heap checks at runtime, without recompilation. Electric Fence allowed one to do that via LD_PRELOAD, so I am sorry, but I stand by what I said - I can see nothing in there that didn't exist in either Efence or my HeapCheck.
I only take an issue with your last paragraph - I certainly didn't leave the code in a graveyard, I released it with an open source license, so that anyone could use it and make his life a bit better. The fact that 10 years later, someone else has now patented the ideas in Electric Fence and HeapCheck, and can now sue me and everyone else using it, is what got me mad (hence the "trolls" comment).
Run Firefox4 and Chrome9 on your machine, and report back... :-)
It's just plain math and a "plotpixel" function... so I'd be happy to know what to change to make it run faster in other browsers - any suggestions?
(the good thing about Javascript - the code is open-source by nature)
On my aging PentiumD/2.8GHz:
Thank you - and as for CUDA, I imagine it will take some time :-) Seriously though, WebGL will do just fine :-)
I, too, saw the speed of Firefox 4 in a pretty simple, math-only benchmark that rotated a 3D object. Run it for yourself and/or see the gathered statistics (bottom of the page). Here is the Reddit discussion where many people run it and confirmed Firefox 4 supremacy.
My naive Python simulator of gravity (200 lines) reached the same conclusion - expansion occurs. See the video and get the code from here: http://users.softlab.ntua.gr/~ttsiod/gravity.html
Which UPnP server SW did you use under your Linux?
I was clearly right, but unfortunately, someone at Slashdot closed the thread I tried to open about this, 6 months ago: http://slashdot.org/submission/1094437/Why-isnt-Google-allowing-searches-over-HTTPS
Use ZFS if you are in OpenSolaris/FreeBSD land, or use a Reed-Solomon tool - a GPL implementation of mine was Slashdotted 2 years ago, here: http://users.softlab.ntua.gr/~ttsiod/rsbep.html
I also use rsync and OpenSolaris/ZFS to keep daily backups. BUT - important: If the content is made of big files that change slightly each day (e.g. VMWARE/VirtualBox disk images), make sure you also use "--inplace" when you do the rsync, so that you take advantage of the copy-on-write semantics of ZFS. For example, I am using rsync to back up a VMWARE server to an OpenSolaris/ZFS fileserver, where the virtual disks are huge "vmdk" files - in the order of 10GB each. These huge files change only a little each day (less than 1%) - rsync would indeed realize this and only copy over the network the parts that changed, but it would store completely new copies in the backup server for each day! (I am assuming here that you would ZFS-snapshot each day). If instead you use the --inplace option of rsync, rsync will not only send the blocks that changed, but it will also only write the blocks that changed - thus, your ZFS will be able to host many years' worth of daily snapshots of these "vmdk", a truly marvelous thing, if you think about it...
And you would be wrong. I've worked in very large projects (in the Telecom industry), and am currently coding specialized C/C++ code generators for the European Space Agency (the kind that actually generate the static, speedy, typesafe code that is appropriate for many projects). I know what you are talking about, and I never implied that Python is the way to go for all kinds of problems. My site has just as much C++ stuff as it does Python (e.g. my realtime 3D renderers) - even x86 SSE asm! What I am trying to show people is that there are many kinds of problems where scripting languages are not only adequate, but in fact the best way to go about... Google uses and advocates Python a lot, and Eric Raymond (esr) explains why a lot better than I ever could (Why Python?). In this day and age, developing speed and code clarity is just as important (if not more) as execution speed. Try Python and you'll know what I mean, when I refer to developing speed... And as for code clarity, the world is moving towards dynamic and type-infering languages (Ocaml, F#) for a reason...
As for the title, what you describe can't happen because of a fortunate side-effect: when compressing, bzip2 (as other compressors) look for previous appearances of a token (in this case, '<title>') and code a reference to it (instead of the full text) to save space. Since "text" and "title" appear all the time in these blocks (at least once for each article), they will NOT be split - they will be encoded as "references", and therefore, what you describe shouldn't happen (I hope :-)
No, actually there is no bug. If you read the contents of the 'show.pl' script, you'll see that it adapts to a missing '' by reading from the next volume - the next recxxx...bz2. :-)
As for the title, what you describe can't happen because of a fortunate side-effect: when compressing, bzip2 (as other compressors) look for previous appearances of a token (in this case, '<title>') and code a reference to it (instead of the full text) to save space.
So you see - no bugs