One... on the AC adapter front: most devices have a USB charge cable available, and you can get auto- and wall-wart adapters now with a "power-only" USB connector in them. You can also get a wall-wart with an auto cigarette lighter socket in it, and use the car adapters only.
Two... my experience with fancy phones and PDAs with MP3 players in them is that because the MP3 player sucks down power for extended periods you're much more likely to have a music player device that's "too low to use" than any other bit of personal kit. When that just means you can't listen to music, that's OK. When that means you can't use your phone, it's not.
I could see a camera in a phone more than an mp3 player in a phone, because a camera doesn't get left on for hours.
For every 1 user that only needs a phone book and voicemail, there is probably 20 that also wants polyphonic ringtones, 10 that wants a colour display and a 100 users that also need text messaging.
You have the numbers backwards.
For every 1 user that needs polyphonic ringtones or a a color display, there's 10 who just want a bloody phone. And EVERYONE benefits from longer battery life.
Text messaging? That's just software. You don't need to build a fancy phone to get text. OK, OK, you can't get text on a 7 segment LED, but that's a bit primitive even for us puritans.
The LG phone I've got is about the most basic one on the list the carrier offered for our area. It's too damn fancy and complex and even if you don't USE the features you're still paying for them in reduced battery life.
go with the ~£25 Nokia 1100.
Oh, a pom.
That explains everything. Look, sunshine, you're in bloody cellphone heaven. Here in the US it's like the third world, except the third bloody world generally has better cellphone service than the US. You don't get a choice of phones when you sign up, you don't usually get to buy a phone and use it with your service because everyone's phones are locked... and not what you guys think of as locked either: there's like four different cellular protocols and most of them don't have any concept of phone portability like GSM does.
So people who are frustrated by crappy cellphones, they probably don't have any of the options you're talking about. Even PAYG isn't PAYG as you know it.
Yah, when work switched carriers they had to switch phones, so we all got these fancy LG phones to replace our old dumb B&W nokia bars. So now:
Battery life sucks, it's less than half... I had to get a charger for my desk because if I forgot to charge it overnight one day the chance of running it flat before I got home was too high.
I can't read the display outside. Color displays for cellphones are just plain wasteful.
The Nokia had three dumb games on it (snake was one, i forget the others). They were great for keeping kids/teens amused, and the battery life was good enough they didn't run it down from ten minutes waiting in line. The LG has some kind of game rental function but the rest of the phone is so messed up there's no way I'm going to activate that.
If iTunes could automatically accept, process and download podcasts from a torrent without the user having to intervene at any point we would definately have a winner on our hands.
If you want it automatic, write an Applescript that nyud-net-ifies the URL of the podcast.
Otherwise, you'll want to make the torrent client a proxy (listening, say, on port 6161) that recognises URLs of podcasts that have torrents available and fetches them, otherwise just do the regular lookup... and then set your network proxy settings to "localhost:6161". The source to tinyproxy is probably a good place to start, I've found it very hackable.
The sooner a peer-peer solution for podcasting is found the better.
Bittorrent should work fine. And don't forget nyud.net works with any slashdotted resource.
Re:Rotor license terms?
on
Effective C#
·
· Score: 1
It's not meant to be incorporated directly into your code.
Then it's worse than worthless.
It's useful for seeing how.NET apis are implemented (if the documentation isn't clear enough).
If it doesn't give me a way to actually USE the.NET APIs, it doesn't matter how the.NET APIs are implemented. If I'm going to use someone else's implementation of the.NET APIs, I'll see how THEY implemented it... that way I don't have to worry about Microsoft sending a front man like SCO after me claiming I stole their bleeding code.
Re:Rotor license terms?
on
Effective C#
·
· Score: 1
take a guess... shared source of course.
Ah. "Non-commercial-use". And they have the gall to complain about the GPL (me, I'm a BSDL fan, but I can live with the GPL... but I'm not touching no-commercial-use source with a 10 foot non-conductive thermally-stable shock-dampened safety-breakaway pole.
Hmmm. BeOS seems to have an interesting file system and GUI, but the OS underneath is a bit language-specific and hoggy for my taste. How about implementing BeFS and the BeOS GUI on top of TRON? You could call it "Beatron" and finally have an OS that's got enough pop-culture references to achieve a kind of pop-Zen perfection and eliminate Microsoft.
I wish Sun would open-source NeWS, then let the Berlin people add OpenGL primitives to it, and see about accelerating THAT. Screw Java, I want to be able to upload Postscript code to the GPU so all my apps get the magical raytraced flaming 3d delete dialogs.
Oh, yeh, man, the RISC code in the second example isn't using the (n&-n) trick from HACKMEM, which is four times faster on a typical processor and would thus reduce the RISC time to... 61 cycles, about the same as the CISC (again, this is unsurprising, since the CISC code is interpreted by microcode that's similar to the RISC code).
The result is that this high-level instruction allows for processing is carried out in roughly one half the time, while at the same time realizing a two-thirds reduction in code size.
Yeh, that's the case I was talking about. First, that's an awfully CISCy RISC they're moving stuff to, with "Register plus scaled register plus offset indirect" as an addressing mode. Converting it to a sane RISC would use two more registers, add two arithmetic instructions at the beginning but eliminate all the complex addressing that's taking up most of the instructions.
I'd build a list that had the forward and back links sequential, then do this:
Now that's 7 instructions, 28-36 bytes depending on whether those constants require an extra word, but they're all short. Apart from memory access (which depends on what's in the cache), you're looking at T(pipeline)+2*T(arithmetic)+7. With a 7 stage pipeline, 2 cycles overhead for arithmetic, the whole thing should be finished in 19 cycles (plus memory overhead, which is independent of the processor). BUT, 6 of those cycles are calculating the offset of the list in the table, and 6 of those cycles are waiting for the pipeline and so overlap previous or subsequent instructions. If there was any previous code that had referenced the process table (which is likely) the result of the first two instructions is probably already in a register.
I'm not going to analyse the larger example like this, but given how badly this one was blown I'll bet they're wrong about that one too. The code size is smaller for the CISC, but the execution time is about the same (since the microinstructions the TRON chip's using are likely similar to the RISC instructions, that's to be expected), and the RISC code can take advantage of intermediate results from previous instructions to further improve its performance.
From what I've heard, its easier to make a risc compiler than a cisc one.
Actually, it's easier to make a simple CISC compiler that produces OK code on a regular CISC like a 68000 or a PDP-11. For these "4th generation" CISCs and things like Altivec or SSE you don't bother, you leave them for library writers and assembler boffins. The ones that are really hard to code for are the 3.5th generation CISC like the VAX and iAPX432 that have instructions designed to help compiler writers like "set up stack frame" that actually slow you down... and anything from Intel. God, Intel makes it rough on compiler writers... iAPX432, i860, and of course IA64.
It's this weird, baroque API that's non-POSIX and not standard C library compatible.
That's not necessarily bad. Particularly in embedded systems, where most of the resources POSIX and stdio manage (files, virtual address spaces, etc) don't exist. Real-time programming deals with an environment more like the internals of the UNIX kernel than userspace, which is why things like microkernels are so attractive even if they don't directly make implementing a POSIX environment any easier... what they do is create an API that works for embedded systems AND general purpose computers.
That's also why Mach is such a dismal failure as a microkernel. It assumes it's got the same kind of resources as a complete POSIX system, like virtual memory.
I've been hearing about the TRON project for something like 20 years now, starting with the TRON microprocessor... the ultimate CISC. We're talking about a processor that has "insert a record into a doubly linked list" as a fundamental instruction. And they're still pushing this super-CISC as an improvement over RISC.
Has anyone outside MITI actually done an objective comparison of TRON with any contemporary RISC? The examples I've seen are ludicrous... comparisons "proving" that TRON is faster than RISC by comparing individual highly specialised TRON instructions with a straightforward unoptimized translation of the same code to an unspecified RISC processor. They don't even do any common subexpression elimination... who would write code like this?
Your cynicism seems to be rather carefully bounded. While much of what you say has merit, surely you're not so naive as you seem about the way Grokster was modelled on Napster: Napster wasn't just a "previous P2P network". It was a P2P network specifically designed and marketed for illegal file sharing, that was its explicit goal right from the start. The fact that the company still exists in any form leaves a bad taste in my mouth.
The clickwheel is too sensitive an input device, it needs too much clearance. The same thing goes for those stupid touchpad controls. The iPod Shuffle has a much better controller than the iPod, or the deives with the little literal joysticks and things.
Hmm. That part didn't get quoted in the article referenced two levels above (or three, I can't find it in all the 2nd amendment debate that's taken over this sub-thread). Indeed, that DOES make a difference.
The one thing that I find worrisome is this: the objective that recipients use it to download copyrighted works and locating and playing copyrighted materials...
It's not illegal to locate, download, and play copyrighted materials. Making them available for download against the wishes of the copyright owner is the actual illegal activity, and the way P2P works you normally make them available when you download them, but... here: I'm about to help you locate, download, and play copyrighted materials. Follow these URLs:
I realise this isn't the kind of "copyrighted materials" he's talking about, but I'd REALLY like to see words like "non-royalty-free" or "restricted distribution" in there somewhere.
The iPod shuffle controls are pretty good, much better than the stupid click wheel. But I'd like a couple of extra buttons because triple-tap to jump to the start of the playlist is annoying.
Disk mode: plays any mp3/mp4/ogg/... files you drop into it, don't worry about integrating it with the player any better than that. Or if you create a player module for WMP or iTunes, do it through copying files around.
Voice synth: tap a button to speak the name of the currently playing song, or speak the next song name when you skip. If I hit NEXT again while you're speaking, jump right away...
USB host mode: plug a flash drive in, and navigate through my music and copy songs to the flash drive. Or from it.
Don't worry about DRM support, save the license fees and assume the user isn't stupid or a crook. Apple's got DRM and music players sewn up, so don't fight them on their own turf.
Remember the volume settings for every song, so when I punch up Sibelius or ease back on Chumbawamba you'll do that for me next time. Even if next time is three months later... it takes less than 100 bytes to store the artist/album/track and level for each song. You're going to have gigabytes to play with, so keep track of songs even if I've deleted them from the flash disk.
Keep track of the play count, last played, and whether I played through to the end for every song. In the same file. And make it a text file or XML so I can sync with it using any computer. In fact, make it comments in an m3u file.
Make the whole thing about the size and shape of a Maglite Solitaire, including making the case out of anodized aluminum. We're talking industrial chic: make it look tough enough that when you drop it at a rave and it's had 150 people stamping on it for 3 hours it's still working.
If you can control the servers running on your computer (services, daemons, inetd, etc), then a firewall is a second layer of defense. Otherwise, it's your first layer of defense. A properly configured "no listeners running" *NIX box has comparable network security to a properly firewalled Windows box, even if you don't run any firewall software on the *NIX box.
It may be possible to lock down the Windows box by turning off all services that open TCP ports, but I have found it difficult to implement in practice.
The studies that got written to point out the evils of pot were funded by DuPont right after they created Nylon.
That's a new one. The one I used to hear all the time was that it was aimed at hemp paper because Hearst (or some other fill-in-the-blanks magnate) wanted to protect their investment in wood-pulp paper mills and/or logging rights.
Slashdot Mirror
One... on the AC adapter front: most devices have a USB charge cable available, and you can get auto- and wall-wart adapters now with a "power-only" USB connector in them. You can also get a wall-wart with an auto cigarette lighter socket in it, and use the car adapters only.
Two... my experience with fancy phones and PDAs with MP3 players in them is that because the MP3 player sucks down power for extended periods you're much more likely to have a music player device that's "too low to use" than any other bit of personal kit. When that just means you can't listen to music, that's OK. When that means you can't use your phone, it's not.
I could see a camera in a phone more than an mp3 player in a phone, because a camera doesn't get left on for hours.
Yeh, particularly the one with the monochrome display.
For every 1 user that only needs a phone book and voicemail, there is probably 20 that also wants polyphonic ringtones, 10 that wants a colour display and a 100 users that also need text messaging.
You have the numbers backwards.
For every 1 user that needs polyphonic ringtones or a a color display, there's 10 who just want a bloody phone. And EVERYONE benefits from longer battery life.
Text messaging? That's just software. You don't need to build a fancy phone to get text. OK, OK, you can't get text on a 7 segment LED, but that's a bit primitive even for us puritans.
Most phone makers to a "basic" phone
The LG phone I've got is about the most basic one on the list the carrier offered for our area. It's too damn fancy and complex and even if you don't USE the features you're still paying for them in reduced battery life.
go with the ~£25 Nokia 1100.
Oh, a pom.
That explains everything. Look, sunshine, you're in bloody cellphone heaven. Here in the US it's like the third world, except the third bloody world generally has better cellphone service than the US. You don't get a choice of phones when you sign up, you don't usually get to buy a phone and use it with your service because everyone's phones are locked... and not what you guys think of as locked either: there's like four different cellular protocols and most of them don't have any concept of phone portability like GSM does.
So people who are frustrated by crappy cellphones, they probably don't have any of the options you're talking about. Even PAYG isn't PAYG as you know it.
Yah, when work switched carriers they had to switch phones, so we all got these fancy LG phones to replace our old dumb B&W nokia bars. So now:
Battery life sucks, it's less than half... I had to get a charger for my desk because if I forgot to charge it overnight one day the chance of running it flat before I got home was too high.
I can't read the display outside. Color displays for cellphones are just plain wasteful.
The Nokia had three dumb games on it (snake was one, i forget the others). They were great for keeping kids/teens amused, and the battery life was good enough they didn't run it down from ten minutes waiting in line. The LG has some kind of game rental function but the rest of the phone is so messed up there's no way I'm going to activate that.
If iTunes could automatically accept, process and download podcasts from a torrent without the user having to intervene at any point we would definately have a winner on our hands.
If you want it automatic, write an Applescript that nyud-net-ifies the URL of the podcast.
Otherwise, you'll want to make the torrent client a proxy (listening, say, on port 6161) that recognises URLs of podcasts that have torrents available and fetches them, otherwise just do the regular lookup... and then set your network proxy settings to "localhost:6161". The source to tinyproxy is probably a good place to start, I've found it very hackable.
The sooner a peer-peer solution for podcasting is found the better.
Bittorrent should work fine. And don't forget nyud.net works with any slashdotted resource.
It's not meant to be incorporated directly into your code.
.NET apis are implemented (if the documentation isn't clear enough).
.NET APIs, it doesn't matter how the .NET APIs are implemented. If I'm going to use someone else's implementation of the .NET APIs, I'll see how THEY implemented it... that way I don't have to worry about Microsoft sending a front man like SCO after me claiming I stole their bleeding code.
Then it's worse than worthless.
It's useful for seeing how
If it doesn't give me a way to actually USE the
take a guess... shared source of course.
Ah. "Non-commercial-use". And they have the gall to complain about the GPL (me, I'm a BSDL fan, but I can live with the GPL... but I'm not touching no-commercial-use source with a 10 foot non-conductive thermally-stable shock-dampened safety-breakaway pole.
Hmmm. BeOS seems to have an interesting file system and GUI, but the OS underneath is a bit language-specific and hoggy for my taste. How about implementing BeFS and the BeOS GUI on top of TRON? You could call it "Beatron" and finally have an OS that's got enough pop-culture references to achieve a kind of pop-Zen perfection and eliminate Microsoft.
Microsoft even released the source code to a FreeBSD CLR implementation called "Rotor".
Under what terms?
I wish Sun would open-source NeWS, then let the Berlin people add OpenGL primitives to it, and see about accelerating THAT. Screw Java, I want to be able to upload Postscript code to the GPU so all my apps get the magical raytraced flaming 3d delete dialogs.
Oh, yeh, man, the RISC code in the second example isn't using the (n&-n) trick from HACKMEM, which is four times faster on a typical processor and would thus reduce the RISC time to ... 61 cycles, about the same as the CISC (again, this is unsurprising, since the CISC code is interpreted by microcode that's similar to the RISC code).
Yeh, that's the case I was talking about. First, that's an awfully CISCy RISC they're moving stuff to, with "Register plus scaled register plus offset indirect" as an addressing mode. Converting it to a sane RISC would use two more registers, add two arithmetic instructions at the beginning but eliminate all the complex addressing that's taking up most of the instructions.
I'd build a list that had the forward and back links sequential, then do this:Now that's 7 instructions, 28-36 bytes depending on whether those constants require an extra word, but they're all short. Apart from memory access (which depends on what's in the cache), you're looking at T(pipeline)+2*T(arithmetic)+7. With a 7 stage pipeline, 2 cycles overhead for arithmetic, the whole thing should be finished in 19 cycles (plus memory overhead, which is independent of the processor). BUT, 6 of those cycles are calculating the offset of the list in the table, and 6 of those cycles are waiting for the pipeline and so overlap previous or subsequent instructions. If there was any previous code that had referenced the process table (which is likely) the result of the first two instructions is probably already in a register.
I'm not going to analyse the larger example like this, but given how badly this one was blown I'll bet they're wrong about that one too. The code size is smaller for the CISC, but the execution time is about the same (since the microinstructions the TRON chip's using are likely similar to the RISC instructions, that's to be expected), and the RISC code can take advantage of intermediate results from previous instructions to further improve its performance.
From what I've heard, its easier to make a risc compiler than a cisc one.
Actually, it's easier to make a simple CISC compiler that produces OK code on a regular CISC like a 68000 or a PDP-11. For these "4th generation" CISCs and things like Altivec or SSE you don't bother, you leave them for library writers and assembler boffins. The ones that are really hard to code for are the 3.5th generation CISC like the VAX and iAPX432 that have instructions designed to help compiler writers like "set up stack frame" that actually slow you down... and anything from Intel. God, Intel makes it rough on compiler writers... iAPX432, i860, and of course IA64.
It's just how it happened.
It's this weird, baroque API that's non-POSIX and not standard C library compatible.
That's not necessarily bad. Particularly in embedded systems, where most of the resources POSIX and stdio manage (files, virtual address spaces, etc) don't exist. Real-time programming deals with an environment more like the internals of the UNIX kernel than userspace, which is why things like microkernels are so attractive even if they don't directly make implementing a POSIX environment any easier... what they do is create an API that works for embedded systems AND general purpose computers.
That's also why Mach is such a dismal failure as a microkernel. It assumes it's got the same kind of resources as a complete POSIX system, like virtual memory.
This diagram on this page shows in general terms how they're addressing this.
Has anyone outside MITI actually done an objective comparison of TRON with any contemporary RISC? The examples I've seen are ludicrous... comparisons "proving" that TRON is faster than RISC by comparing individual highly specialised TRON instructions with a straightforward unoptimized translation of the same code to an unspecified RISC processor. They don't even do any common subexpression elimination... who would write code like this? http://tronweb.super-nova.co.jp/tronvlsicpu.html
Your cynicism seems to be rather carefully bounded. While much of what you say has merit, surely you're not so naive as you seem about the way Grokster was modelled on Napster: Napster wasn't just a "previous P2P network". It was a P2P network specifically designed and marketed for illegal file sharing, that was its explicit goal right from the start. The fact that the company still exists in any form leaves a bad taste in my mouth.
The clickwheel is too sensitive an input device, it needs too much clearance. The same thing goes for those stupid touchpad controls. The iPod Shuffle has a much better controller than the iPod, or the deives with the little literal joysticks and things.
I don't agree that is what the ruling says...
Hmm. That part didn't get quoted in the article referenced two levels above (or three, I can't find it in all the 2nd amendment debate that's taken over this sub-thread). Indeed, that DOES make a difference.
The one thing that I find worrisome is this: the objective that recipients use it to download copyrighted works and locating and playing copyrighted materials...
It's not illegal to locate, download, and play copyrighted materials. Making them available for download against the wishes of the copyright owner is the actual illegal activity, and the way P2P works you normally make them available when you download them, but... here: I'm about to help you locate, download, and play copyrighted materials. Follow these URLs:
http://magnatune.com/
http://www.lujorecords.com/
http://www.columbia.edu/cu/cuo/audio.html
http://www.pianosociety.com/
http://www.serg.vangennip.com/www/piano.html
http://zebox.com/woodmoran/music/
I realise this isn't the kind of "copyrighted materials" he's talking about, but I'd REALLY like to see words like "non-royalty-free" or "restricted distribution" in there somewhere.
Built-in clip instead of the stupid lanyard.
The iPod shuffle controls are pretty good, much better than the stupid click wheel. But I'd like a couple of extra buttons because triple-tap to jump to the start of the playlist is annoying.
Disk mode: plays any mp3/mp4/ogg/... files you drop into it, don't worry about integrating it with the player any better than that. Or if you create a player module for WMP or iTunes, do it through copying files around.
Voice synth: tap a button to speak the name of the currently playing song, or speak the next song name when you skip. If I hit NEXT again while you're speaking, jump right away...
USB host mode: plug a flash drive in, and navigate through my music and copy songs to the flash drive. Or from it.
Don't worry about DRM support, save the license fees and assume the user isn't stupid or a crook. Apple's got DRM and music players sewn up, so don't fight them on their own turf.
Remember the volume settings for every song, so when I punch up Sibelius or ease back on Chumbawamba you'll do that for me next time. Even if next time is three months later... it takes less than 100 bytes to store the artist/album/track and level for each song. You're going to have gigabytes to play with, so keep track of songs even if I've deleted them from the flash disk.
Keep track of the play count, last played, and whether I played through to the end for every song. In the same file. And make it a text file or XML so I can sync with it using any computer. In fact, make it comments in an m3u file.
Make the whole thing about the size and shape of a Maglite Solitaire, including making the case out of anodized aluminum. We're talking industrial chic: make it look tough enough that when you drop it at a rave and it's had 150 people stamping on it for 3 hours it's still working.
If you can control the servers running on your computer (services, daemons, inetd, etc), then a firewall is a second layer of defense. Otherwise, it's your first layer of defense. A properly configured "no listeners running" *NIX box has comparable network security to a properly firewalled Windows box, even if you don't run any firewall software on the *NIX box.
It may be possible to lock down the Windows box by turning off all services that open TCP ports, but I have found it difficult to implement in practice.
The studies that got written to point out the evils of pot were funded by DuPont right after they created Nylon.
That's a new one. The one I used to hear all the time was that it was aimed at hemp paper because Hearst (or some other fill-in-the-blanks magnate) wanted to protect their investment in wood-pulp paper mills and/or logging rights.