How about noticing that that post isn't exactly a model of valid and intelligent criticism.
I don't care how reasoned the points are in this or any other argument; when someone uses insults to advance their point people are going to react emotionally and any useful points are lost in the noise of the shouting match that ensues.
By rewriting the code you clean things up and make it easier for future programers to understand what the code is doing.
So that they can rewrite it themselves when they have to look at it?
Seriously though... If you're working on a piece of code that almost works but are unhappy with some part, refactor the part you don't like and go on. It'll be faster then a full rewrite and you don't lose all those bug fixes that took so long to get right in the first place.
Yup, that's true. But... at the application level pulling out all the a stops (5 slice packets and no error bits) and with a quality radio signal you'll get 723 kbps (that's bits). Uncompressed CD quality stereo is 16 bits * 44100 samples per second * 2 channels or 1400 kbps. You can not transmit uncompressed cd-quality audio over Bluetooth.
If you want to transmit compressed audio you can, however since compression schemes are vulnerable to noise you have to turn on the Error Detection bits and that drops your throughput to around 500 kbps. Less if you're not willing to take all of the BT bandwidth.
Assuming you're happy with transcoded/compressed audio from your $300 player lets look at the ramification: * you have compressed audio * you have added transcoding HW or SW to the player * you have added decoding hardware to the headphones * you have added 2 bluetooth radios (player and headphones) * you can not replace your headphones with 3rd party headphones * you have battery management issues with your headphones. * you have interference issues with microwaves, 802.11b and 802.11g APs and other BT devices * the extra hardware will cost $20 to manufacture, so your player now costs an extra $60 to $80
I repeat my original statement, Bluetooth is not an appropriate technology for stereo headphones.
There's no way to maximize the thing to get the most out of the screen real estate. You can drag the thing larger, but you absolutely, positively, cannot fill the screen.
Actually, this is a Mac-ism that I didn't understand when I switched, but now I really like it. The Maximize button toggles the app between it's small size and it's big size. iTunes is a little odd in that most apps go between the size you last dragged it to and "big enough"; where big enough means big enough to display everything in the window, not necessarily the whole screen.
On the Mac Option-Click (alt) makes iTunes big enough. That's the standard Mac short cut for right clicking. Try Right-Clicking or Alt-Clicking the Maximize button and see what happens.
BTW I agree with you. As much as I like the Mac way of things (more Kool-aid? hey thanks) I wish that they had stuck a little better with the Windows UI guidelines for their windows apps.
It has a real problem playing one playlist while I do things to other songs. I start playing something in a list, then go elsewhere in the interface to edit tags or something, and when that song stops, the damn thing stops playing because I'm no longer on the playlist that I was on when I started playing.
My guess... You are not playing a playlist. You are using the browse pane to select a sub-set of your library and then moving to another part of your library to edit things. If the tracks in the playlist that is playing are no longer selected either via browse or search then iTunes doesn't know how what track to go on to.
Use a real playlist to play music from if your going to be doing a lot of editing in your library. It's trivial to make a one off playlist, just select a bunch of tracks and drag them to a blank spot in the source pane; iTunes will make a playlist with all those tracks.
I have seen a pre-release version of Longhorn (at WinHEC, New Orleans) and they were showing off a system that was functionally equivalent to Expose in that it allowed switching between thumbnailed versions of running applications.
I was different from Expose in a number of significant ways.
Cypress's WIreless USB chipset is simply a USB device with a serial link to the other radio. USB traffic does not go across the wireless link. Notice the spec sheet says transparent to design at operating system level that means it's not transparent to the hardware or firmware.
This is simply marketing spin on a processor with a USB SIE and a custom radio link.
Even more important to remember is that this is not a new definition. An online 1828 dictionary defines piracy as "The robbing of another by taking his writings."
That's 175 years ago. I think it's time to accept that language changes.
Everyone knows that the MOST important factor is 'quietness', and we all know that's where apple really takes the cake! Not with the XServe they don't. They sound like a vacuum cleaner with a sore throat.
Assuming you got the same letter I did, or at least a similiar one, check that it really is any MS product. I thought that it was cool until I noticed Office X was not avalable. In fact, I saw no Mac SW at all, Windows only.
And where do you think that 2nd reference comes from?
I assume you're implying that it's a recent addition...
An online Websters dictionary from 1828 defines it as
PI'RACY, n. [L. piratica, from Gr. to attempt, to dare, to enterprise, whence L. periculum, experior; Eng. to fare.]
1. The act, practice or crime of robbing on the high seas; the taking of property from others by open violence and without authority, on the sea; a crime that answers to robbery on land.
Other acts than robbery on the high seas, are declared by statute to be piracy. See Act of Congress, April 30, 1790.
2. The robbing of another by taking his writings.
Pirate
(Pi"rate) n. [L. pirata, Gr. fr. to attempt, undertake, from making attempts or attacks on ships, an attempt, trial; akin to E. peril: cf. F. pirate. See Peril.]
1. A robber on the high seas; one who by open violence takes the property of another on the high seas; especially, one who makes it his business to cruise for robbery or plunder; a freebooter on the seas; also, one who steals in a harbor.
2. An armed ship or vessel which sails without a legal commission, for the purpose of plundering other vessels on the high seas.
3. One who infringes the law of copyright, or publishes the work of an author without permission.
Maybe it's just me but I think that 175 years later it's time to accept that language changes.
This won't work because there are a number of mailing lists and email newsletters that have large numbers of subscribers. Can you imaging what the yearly cost of sending the comp.risks digest would be?
Pirate
(Pi"rate), v. t. To publish, as books or writings, without the permission of the author.
It doen't look like there's a good online dictionary with better dates in it, so that the best I can do for now. So basically what I'm trying to say is, 1828 is a long time ago. 175 years later it's time to accept that language changes.
if you have even one USB (1) device, your whole chain will slow down to accomodate it
Funny this had the subject "what a load". USB2 hubs rate match for the devices under them. Only the wire between the last hub and the device runs at the old speeds. The whole network contiues to full full out.
I don't know much about Windows programming myself, but it seems like if you want to really get into the guts of things, you'll have to deal with MFC and COM.
Sigh. Any comment that starts with this kind of statement is not insightful.
MFC is not required for windows application programming, but it probably is for student projects. Jeff Prosise's book Programming Windows with MFC is the book to use in this case. You'll find that MFC makes certian standard things very very easy to make. Unfortunetly trying to go outside those standard things starts getting very hard very fast. At that point you'll want to program straight to the Win32 interface. If you need to do this Charles Petzold's book Programming Windows is the way to go.
COM is required in very few places in windows programming. In half the places where it is required, direct X mostly, it's wrapped in such a way that you don't need to learn anything about it. The only student projects that will need COM for anything will be projects about COM.
For app level coding in C using the basic Win32 calls look for Charles Petzold Programming Windows, 5th Edition. For MFC programming look for Jeff Prosise Programming Windows with MFC. Both of these are excellent resources.
I've yet to find a device driver book that's better than the DDK help files and sample code.
Slashdot Mirror
How about noticing that that post isn't exactly a model of valid and intelligent criticism.
I don't care how reasoned the points are in this or any other argument; when someone uses insults to advance their point people are going to react emotionally and any useful points are lost in the noise of the shouting match that ensues.
OK, so what's the correct mod for and "Insightful" or "Informative" post that is neither?
By rewriting the code you clean things up and make it easier for future programers to understand what the code is doing.
So that they can rewrite it themselves when they have to look at it?
Seriously though... If you're working on a piece of code that almost works but are unhappy with some part, refactor the part you don't like and go on. It'll be faster then a full rewrite and you don't lose all those bug fixes that took so long to get right in the first place.
Bluetooth can get up to 1Mibps.
Yup, that's true. But... at the application level pulling out all the a stops (5 slice packets and no error bits) and with a quality radio signal you'll get 723 kbps (that's bits). Uncompressed CD quality stereo is 16 bits * 44100 samples per second * 2 channels or 1400 kbps. You can not transmit uncompressed cd-quality audio over Bluetooth.
If you want to transmit compressed audio you can, however since compression schemes are vulnerable to noise you have to turn on the Error Detection bits and that drops your throughput to around 500 kbps. Less if you're not willing to take all of the BT bandwidth.
Assuming you're happy with transcoded/compressed audio from your $300 player lets look at the ramification:
* you have compressed audio
* you have added transcoding HW or SW to the player
* you have added decoding hardware to the headphones
* you have added 2 bluetooth radios (player and headphones)
* you can not replace your headphones with 3rd party headphones
* you have battery management issues with your headphones.
* you have interference issues with microwaves, 802.11b and 802.11g APs and other BT devices
* the extra hardware will cost $20 to manufacture, so your player now costs an extra $60 to $80
I repeat my original statement, Bluetooth is not an appropriate technology for stereo headphones.
Bluetooth does not have the bandwidth to run stereo headphones... But, If you willing to listen to you music in phone quality mono you're good.
There's no way to maximize the thing to get the most out of the screen real estate. You can drag the thing larger, but you absolutely, positively, cannot fill the screen.
Actually, this is a Mac-ism that I didn't understand when I switched, but now I really like it. The Maximize button toggles the app between it's small size and it's big size. iTunes is a little odd in that most apps go between the size you last dragged it to and "big enough"; where big enough means big enough to display everything in the window, not necessarily the whole screen.
On the Mac Option-Click (alt) makes iTunes big enough. That's the standard Mac short cut for right clicking. Try Right-Clicking or Alt-Clicking the Maximize button and see what happens.
BTW I agree with you. As much as I like the Mac way of things (more Kool-aid? hey thanks) I wish that they had stuck a little better with the Windows UI guidelines for their windows apps.
It has a real problem playing one playlist while I do things to other songs. I start playing something in a list, then go elsewhere in the interface to edit tags or something, and when that song stops, the damn thing stops playing because I'm no longer on the playlist that I was on when I started playing.
My guess... You are not playing a playlist. You are using the browse pane to select a sub-set of your library and then moving to another part of your library to edit things. If the tracks in the playlist that is playing are no longer selected either via browse or search then iTunes doesn't know how what track to go on to.
Use a real playlist to play music from if your going to be doing a lot of editing in your library. It's trivial to make a one off playlist, just select a bunch of tracks and drag them to a blank spot in the source pane; iTunes will make a playlist with all those tracks.
I have seen a pre-release version of Longhorn (at WinHEC, New Orleans) and they were showing off a system that was functionally equivalent to Expose in that it allowed switching between thumbnailed versions of running applications.
I was different from Expose in a number of significant ways.
Cypress's WIreless USB chipset is simply a USB device with a serial link to the other radio. USB traffic does not go across the wireless link. Notice the spec sheet says transparent to design at operating system level that means it's not transparent to the hardware or firmware.
This is simply marketing spin on a processor with a USB SIE and a custom radio link.
Even more important to remember is that this is not a new definition. An online 1828 dictionary defines piracy as "The robbing of another by taking his writings."
That's 175 years ago. I think it's time to accept that language changes.
Everyone knows that the MOST important factor is 'quietness', and we all know that's where apple really takes the cake!
Not with the XServe they don't. They sound like a vacuum cleaner with a sore throat.
Assuming you got the same letter I did, or at least a similiar one, check that it really is any MS product. I thought that it was cool until I noticed Office X was not avalable. In fact, I saw no Mac SW at all, Windows only.
I assume you're implying that it's a recent addition...
An online Websters dictionary from 1828 defines it as
A 1913 Websters Dictionary defines it as:
Maybe it's just me but I think that 175 years later it's time to accept that language changes.
-rrThis won't work because there are a number of mailing lists and email newsletters that have large numbers of subscribers. Can you imaging what the yearly cost of sending the comp.risks digest would be?
-rr
Self powered hubs, those that are plugged into the wall or on the back of a machine give you 5v at up to 500 mA. 2.5 Watts.
Bus powered hubs, those that get their power from USB provide 5v at 100 mA. For a grand total of 1 Watt.
It could take quite a bit of time to recharge at that rate.
-rr
A friend of mine did this. He bought a 100 pounds of silly putty, broke it into one pound chunks and sold them for $12.
100 pounds of silly putty is about the size of two boxes of printer paper.
Playing with a pound of silly putty is so much cooler that one of the dinky little eggs.
-rr
-rr
The company that makes the electric motor their using is AC Propulsion, and they make a kick ass 100% electric vehicle with that same motor.
-rr
Let's see A quick web search turns up an online Websters 1828 dictionary that contains:
and an online Websters 1913 dictionary that contains
It doen't look like there's a good online dictionary with better dates in it, so that the best I can do for now. So basically what I'm trying to say is, 1828 is a long time ago. 175 years later it's time to accept that language changes.
-rr
I wish he'd stop tinkering with these films. It's not actually possible to get a copy of the version of the movie I saw initially.
-rr
This as at +5 already so I can't help it that way, but this deserves a big "Hell Yeah, that man knows what he's talking about and is articulate too".
If you're working from home treat it like the bussiness it is.
-rr
FWIW, Plan 9's source has no #if's and there are no machine dependent #ifdefs in any of the source[1] and it runs on a bunch of architectures.
Plan 9 successor, Inferno, has no #if's and no #ifdef's[2] and runs on even more architectures.
In fact Plan 9/Inferno compiler suite doesn't even support #if [1].
-rr
[1] http://www.lysator.liu.se/c/plan9c.html
[2] The Practice of Programming by Kernighan and Pike
Sigh. Any comment that starts with this kind of statement is not insightful.
MFC is not required for windows application programming, but it probably is for student projects. Jeff Prosise's book Programming Windows with MFC is the book to use in this case. You'll find that MFC makes certian standard things very very easy to make. Unfortunetly trying to go outside those standard things starts getting very hard very fast. At that point you'll want to program straight to the Win32 interface. If you need to do this Charles Petzold's book Programming Windows is the way to go.
COM is required in very few places in windows programming. In half the places where it is required, direct X mostly, it's wrapped in such a way that you don't need to learn anything about it. The only student projects that will need COM for anything will be projects about COM.
-rr
For app level coding in C using the basic Win32 calls look for Charles Petzold Programming Windows, 5th Edition. For MFC programming look for Jeff Prosise Programming Windows with MFC. Both of these are excellent resources.
I've yet to find a device driver book that's better than the DDK help files and sample code.
-rr