Yah, "1/3 the price of Portland Cement"... if there was a substance that was cheaper than concrete and nearly as strong it would already be in wide use in construction.
I listed multiple options, of which leaving fiber dark was simply one of them.
The bandwidth is costing them money one way or another. They could leave the fiber dark, they could resell the bandwidth to other companies, they could avoid additional capital costs on the future by using the fiber that they have allocated to Youtube. Allocating that resource to Youtube prevents them from allocating it in other ways, therefore that bandwidth IS costing them money.
That's why I wrote "one reason". OpenMoko had serious problems, yes, but one of them (from the point of the carriers) was that they couldn't lock it down.
If they weren't using it for Youtube they could leave it dark, saving power costs, or deferring future expenditures, or provide transit for other companies and receive income from them.
Re:GTV? Get permission from Philips first...
on
I Want My GTV
·
· Score: 1
Maybe Google's turning into Apple. "iPhone" is owned by Cisco? So what?
I wouldn't call an 8-bit monitor a kernel, but if I were to do one I'd take advantage of the fact that JSR STROUT on the Apple II outputs a whole string. Then I'd use JMP STROUT so I didn't have to include my own RTS. Bet you could get that under 20 bytes.
If you give up the requirement of making it a complete UNIX executables and making UNIX system calls, I bet I could come up with a version for an IBM 1620 or some other old iron where "punch" was a native instruction that's smaller than that.
... and from this we can deduce that, since there were open for you before your call to main() ever gets executed, that there's startup code in there somewhere to open stdin, stdout, stderr, and tie them to 3 file descriptors. In fact, several dead-tree manuals point this out - that the startup code initializes these for you before your code executes.
I remember the first time that happened automatically, when we upgraded from version 6 to version 7.
fd0, fd1, and fd2 are opened by your parent process. stdin, stdout, and stderr may or may not be created from these by crt0.o... in Version 6 UNIX stdio was pulled in with -lS and initialized the first time you called a stdio routine. If you didn't use stdio and just used the default C runtime you got old unbuffered variants that worked directly on file descriptors. You had to be careful using stdio on Version 6 because this was before the bourne shell... shell scripts ran by reading directly from fd0, and "if", "while" and "goto" were programs that seeked around on stdin looking for lines beginning with a ":". Throw a stdio program in the wrong place and it could eat the whole script after it.
Actually, now I think of it, UNIX used the ability of the PDP-11 to recover from a page fault to dynamically extend the stack by trapping stack probes in function preambles, adjusting the stack break, and resuming the interrupted instruction. This caused some pain in some of the early ports to CPUs that couldn't recover from a page fault in all cases. I seem to recall reading about a 68000 port using a specific instruction that happened to be recoverable for stack probes...
The fact that people would even still use C at all for anything anywhere ever shocks me.
The fact that people still use oldschool Algol/Simula-style languages instead of fully reflective languages like Lisp and Smalltalk has been shocking me since the '70s... so get used to being shocked. People just can't let go of these high level assemblers like Java and C#.
UNIX used the sticky bit instead. UNIX also supported Split I&D on the 11/70 before M+ came out with Split I&D support on RSX.
I don't think you're remembering right about overlays on RSX. I know I spent WAY too much time waiting for TKB on RSX because it was sitting there trying to cram stuff into overlays. Also, while later PDP-11s technically could support demand paging the 8k page size in a max of 64k addressible memory made it a marginal technique, and I'm pretty sure it was never used, even by M+.
UNIX supported shared code, too. We had over 35 users at a time on the Cory Hall 11/70 at Berkeley. It was OK under Version 6, but got painfully slow during finals week after they upgraded to Version 7. The Math/Stat department had an 11/60 and could only handle 8 users under UNIX, almost 20 under RSTS... but nobody wanted to use RSTS. We called it "Really Shitty Time Sharing".
Some of the guys managed to patch RSTS Basic+ to run under UNIX by taking advantage of the fact that UNIX used the TRAP instruction for system calls and RSTS used the IOT instruction, by cramming an IOT handler into the half a kilobyte DEC had left for the stack at the beginning of the core image to emulate the RSTS calls that Basic+ needed. That way they could upgrade the business school to UNIX and get rid of the last RSTS holdout on campus.
Version 6 UNIX. I didn't abuse a.out as badly as this example abuses elf, though.
Really, with a.out, it wasn't abuse. That format LIKED these kinds of games. When I was hacking in Forth I wrote a "snapshot" word that did something like
: snapshot fork dup 0= if drop abort then waitpid -1 = if 0 else " mv core snap.out; patch-to-executable snap.out" system 1 then;
Where patch-to-executable took advantage of the fact that an a.out was basically a core dump with some extra segments... and you could leave those segments off if you needed to.:)
I did some nasty stuff on RSX-11, though. Portable file and terminal I/O was a pain in the butt, because text files were variant record files with each line having a count and a length and a record/line type field and IIRC occasional block alignment issues, so to read and write text files in Forth I had a FORTRAN main that called Forth through an assembly glue routine, then called back to FORTRAN for textfile I/O. Also got tired of FORTRAN formatted I/O so I wrote a version of sprintf for my RATFOR code that used assembly glue to implement varargs in FORTRAN. Ah, the good old days...
One reason Android beat out Openmoko was because Google was willing to make a platform that carriers could turn into a walled garden if they wanted to, while Openmoko was designed to NOT be locked down.
Sure, technically Google isn't doing evil here. They're just enabling AT&T to do it.
While able to process images more quickly than conventional biometric identification techniques such as whole face recognition, the system's recognition rates were comparatively low and researchers recommend it as an addition to existing biometrics rather than a replacement.
I really don't trust what Adobe says about this. They have a history of refusing to use native Apple APIs (sometimes with good reason, like refusing to port Photoshop directly to Yellow Box in '97, sometimes with less reason... like sticking with the older versions of Carbon). They could well be expecting Apple to implement DirectX for them.
If you want any kind of security you need the situation where the user asks the administrator "Can I install WeatherBug?" and the administrator says "No!".
I spent a lot of time as a network admin, and I only once had a user repeatedly infected by deliberately installing malware. LOTS of people infected by clicking 'oh, sure, go ahead and infect me' over and over again. But it seems to be a LOT easier for people to learn from being bitten by installing things than from just clicking "go ahead" on a dialog.
So... the big problem is not people deliberately installing things that bite them, it's people accidentally installing things because the system made it hard to tell that this time they're installing a virus instead of any of the three thousand other things that open up confusing dialog boxes. I think you'd get about 96.44% fewer repeat incidents if you changed the user interface from:
Browser asks user "A webpage you probably shouldn't trust has asked me to do something that's probably stupid, should I do it?"
To:
Browser tells user "I just downloaded a file into your downloads directory."
And let the user open the folder and have an opportunity to go "oh, that's probably something I don't want to open".
Because their computer is ALWAYS asking them "hey, can I do something that might be stupid?", so it's easy to reflexivly click "infect me".
The biggest security problems are operating systems and applications that build in "exploit me harder" APIs and user interfaces like ActiveX and 'Open "Safe" files after downloading'.
Microsoft is the poster boy for this, with justification, but every browser company is guilty to some extent. There are no exceptions.
The antivirus companies have been pushing antivirus software for handheld devices since 1999.
In the succeeding decade... so far as I'm aware... the damage caused by viruses on handhelds, ALL handhelds, has been less than the damage due to one false positive incident caused by Norton Antivirus shortly after the pointless hubbub over the Palm "Phage" malware.
Antivirus software for handhelds... just say "no".
Slashdot Mirror
Yes, you pointed it out as an option
I pointed out three options.
Yah, "1/3 the price of Portland Cement"... if there was a substance that was cheaper than concrete and nearly as strong it would already be in wide use in construction.
Yes, but if you can offset higher costs by lighting it up and get a return on the sunk costs, it would be silly to not do it.
Someone else who couldn't be arsed to follow the thread.
I listed multiple options, of which leaving fiber dark was simply one of them. See here.
The bottom line is they're paying for it one way or another. It's not free. Their bill is not zero.
Well, duh.
I listed multiple options, of which leaving fiber dark was simply one of them.
The bandwidth is costing them money one way or another. They could leave the fiber dark, they could resell the bandwidth to other companies, they could avoid additional capital costs on the future by using the fiber that they have allocated to Youtube. Allocating that resource to Youtube prevents them from allocating it in other ways, therefore that bandwidth IS costing them money.
It's a sunk cost, and leaving it dark is cheaper than lighting it up.
That's why I wrote "one reason". OpenMoko had serious problems, yes, but one of them (from the point of the carriers) was that they couldn't lock it down.
If they weren't using it for Youtube they could leave it dark, saving power costs, or deferring future expenditures, or provide transit for other companies and receive income from them.
Maybe Google's turning into Apple. "iPhone" is owned by Cisco? So what?
I wouldn't call an 8-bit monitor a kernel, but if I were to do one I'd take advantage of the fact that JSR STROUT on the Apple II outputs a whole string. Then I'd use JMP STROUT so I didn't have to include my own RTS. Bet you could get that under 20 bytes.
After 30 years, who remembers?
If you give up the requirement of making it a complete UNIX executables and making UNIX system calls, I bet I could come up with a version for an IBM 1620 or some other old iron where "punch" was a native instruction that's smaller than that.
... and from this we can deduce that, since there were open for you before your call to main() ever gets executed, that there's startup code in there somewhere to open stdin, stdout, stderr, and tie them to 3 file descriptors. In fact, several dead-tree manuals point this out - that the startup code initializes these for you before your code executes.
I remember the first time that happened automatically, when we upgraded from version 6 to version 7.
fd0, fd1, and fd2 are opened by your parent process. stdin, stdout, and stderr may or may not be created from these by crt0.o... in Version 6 UNIX stdio was pulled in with -lS and initialized the first time you called a stdio routine. If you didn't use stdio and just used the default C runtime you got old unbuffered variants that worked directly on file descriptors. You had to be careful using stdio on Version 6 because this was before the bourne shell... shell scripts ran by reading directly from fd0, and "if", "while" and "goto" were programs that seeked around on stdin looking for lines beginning with a ":". Throw a stdio program in the wrong place and it could eat the whole script after it.
Actually, now I think of it, UNIX used the ability of the PDP-11 to recover from a page fault to dynamically extend the stack by trapping stack probes in function preambles, adjusting the stack break, and resuming the interrupted instruction. This caused some pain in some of the early ports to CPUs that couldn't recover from a page fault in all cases. I seem to recall reading about a 68000 port using a specific instruction that happened to be recoverable for stack probes...
Fortran - 1957
Lisp - 1958
Algol - 1958
Simula - 1967
Smalltalk - 1969
C - 1972
C++ - 1983
The fact that people would even still use C at all for anything anywhere ever shocks me.
The fact that people still use oldschool Algol/Simula-style languages instead of fully reflective languages like Lisp and Smalltalk has been shocking me since the '70s... so get used to being shocked. People just can't let go of these high level assemblers like Java and C#.
Don't forget the 4k address space and 12 bit words. :)
I don't think Un*x ever did.
UNIX used the sticky bit instead. UNIX also supported Split I&D on the 11/70 before M+ came out with Split I&D support on RSX.
I don't think you're remembering right about overlays on RSX. I know I spent WAY too much time waiting for TKB on RSX because it was sitting there trying to cram stuff into overlays. Also, while later PDP-11s technically could support demand paging the 8k page size in a max of 64k addressible memory made it a marginal technique, and I'm pretty sure it was never used, even by M+.
UNIX supported shared code, too. We had over 35 users at a time on the Cory Hall 11/70 at Berkeley. It was OK under Version 6, but got painfully slow during finals week after they upgraded to Version 7. The Math/Stat department had an 11/60 and could only handle 8 users under UNIX, almost 20 under RSTS... but nobody wanted to use RSTS. We called it "Really Shitty Time Sharing".
Some of the guys managed to patch RSTS Basic+ to run under UNIX by taking advantage of the fact that UNIX used the TRAP instruction for system calls and RSTS used the IOT instruction, by cramming an IOT handler into the half a kilobyte DEC had left for the stack at the beginning of the core image to emulate the RSTS calls that Basic+ needed. That way they could upgrade the business school to UNIX and get rid of the last RSTS holdout on campus.
Was that in RSX11-M?
Version 6 UNIX. I didn't abuse a.out as badly as this example abuses elf, though.
Really, with a.out, it wasn't abuse. That format LIKED these kinds of games. When I was hacking in Forth I wrote a "snapshot" word that did something like
Where patch-to-executable took advantage of the fact that an a.out was basically a core dump with some extra segments... and you could leave those segments off if you needed to. :)
I did some nasty stuff on RSX-11, though. Portable file and terminal I/O was a pain in the butt, because text files were variant record files with each line having a count and a length and a record/line type field and IIRC occasional block alignment issues, so to read and write text files in Forth I had a FORTRAN main that called Forth through an assembly glue routine, then called back to FORTRAN for textfile I/O. Also got tired of FORTRAN formatted I/O so I wrote a version of sprintf for my RATFOR code that used assembly glue to implement varargs in FORTRAN. Ah, the good old days...
*sigh*
Been there done that... on the PDP-11 in 1979.
One reason Android beat out Openmoko was because Google was willing to make a platform that carriers could turn into a walled garden if they wanted to, while Openmoko was designed to NOT be locked down.
Sure, technically Google isn't doing evil here. They're just enabling AT&T to do it.
Did the submitter read the story?
While able to process images more quickly than conventional biometric identification techniques such as whole face recognition, the system's recognition rates were comparatively low and researchers recommend it as an addition to existing biometrics rather than a replacement.
It's a search that's expected to take tens of thousands of years. Don't worry about the lack of results yet.
I really don't trust what Adobe says about this. They have a history of refusing to use native Apple APIs (sometimes with good reason, like refusing to port Photoshop directly to Yellow Box in '97, sometimes with less reason... like sticking with the older versions of Carbon). They could well be expecting Apple to implement DirectX for them.
If you want any kind of security you need the situation where the user asks the administrator "Can I install WeatherBug?" and the administrator says "No!".
I spent a lot of time as a network admin, and I only once had a user repeatedly infected by deliberately installing malware. LOTS of people infected by clicking 'oh, sure, go ahead and infect me' over and over again. But it seems to be a LOT easier for people to learn from being bitten by installing things than from just clicking "go ahead" on a dialog.
So... the big problem is not people deliberately installing things that bite them, it's people accidentally installing things because the system made it hard to tell that this time they're installing a virus instead of any of the three thousand other things that open up confusing dialog boxes. I think you'd get about 96.44% fewer repeat incidents if you changed the user interface from:
Browser asks user "A webpage you probably shouldn't trust has asked me to do something that's probably stupid, should I do it?"
To:
Browser tells user "I just downloaded a file into your downloads directory."
And let the user open the folder and have an opportunity to go "oh, that's probably something I don't want to open".
Because their computer is ALWAYS asking them "hey, can I do something that might be stupid?", so it's easy to reflexivly click "infect me".
Or Apple... or Mozilla...
The biggest security problems are operating systems and applications that build in "exploit me harder" APIs and user interfaces like ActiveX and 'Open "Safe" files after downloading'.
Microsoft is the poster boy for this, with justification, but every browser company is guilty to some extent. There are no exceptions.
The antivirus companies have been pushing antivirus software for handheld devices since 1999.
In the succeeding decade... so far as I'm aware... the damage caused by viruses on handhelds, ALL handhelds, has been less than the damage due to one false positive incident caused by Norton Antivirus shortly after the pointless hubbub over the Palm "Phage" malware.
Antivirus software for handhelds... just say "no".