Not all useful apps are hundreds of megs in size. Without knowing anything about the apps our company produces, or what they do, it is rather arrogant to presume anything about their usefulness. And from what I've been told (as I'm not the developer), the total image and icon size is in the megabyte, not kilobyte, range. I'd assume much more of that space is having to include images for every supported model and screen resolution rather then the icons. I chose the icon sizes above as an example just to show how seemingly arbitrary Apple is about changing everything from one model to the next. Why in the world go to a 58x58 icon when there is a 57x57 icon available? Is that extra 115 pixels going to make the app all that much more beautiful? Is it worth the extra work, times every single iOS developer in the world, to gain those 115 pixels? How many millions of man-hours of productivity world wide have been wasted recreating icon and image sets to deal with each and every change iOS makes to their screen? Large shops with hundreds of developers probably don't notice or care, but smaller developers certainly do.
> The high-resolution image assets that developers are required to add also contributes to the size of an app.
--
This. Having to provide icons at 57x57 and 58x58, just for two examples out of dozens, is asinine. Our app code is dwarfed by the image collection size just to provide the minimum number of icons and load screens required.
HP LaserJet III - Can't seem to kill it. Slow, by today's standards, but still prints like a champ. It's at home or I'd pull up the page stats. I think its over 1,000,000 prints, as it was used at the office for at least 15 years before they retired it (couldn't get a parallel port to run it off of easily) and I brought it home.
HP 28C - While not everyone's favorite HP calculator, my 28C was purchased when I was a freshman in college in 1985, and still used daily. As a matter of fact, I think it's only on it's fourth or fifth set of batteries. They just never die.
In addition to the modem control signals, USB adapters also really mess up the timing of the signals. Some RS-232 hardware does not use any flow control, and relies on character timeouts to detect end of message. USB ports packetize the data, and can break up the packets in unpredictable places, so that delays can appear in the message, causing the other side to detect an end of message too soon. Also, some equipment uses the control lines such as RTS/CTS, DSR/DTR, RI, and DCD for I/O purposes. In DOS, it wasn't that hard to get somewhat decent timing to create and/or detect signals of specific duration with these pins, using them as essentially free digital I/O. With a USB to serial adapter, especially under Windows, it is nearly impossible to get any precision timing. Add to that another layer of VM, and it just gets worse. How bad this is really depends on the chipset and drivers. I've had more luck with PL2303 based devices than FTDI along these lines, but for some applications, USB to serial just won't work.
Well, the meanings of words change, anyway, but not always for the best. At best, I would have called this a biomechanical cat, not a bionic one, but I'm in my 40's, so new uses of old terms bothers me more than some.
Absolutely not. Verizon can have all the patents they want, they just can't use them as a way to prevent another carrier from offering a competing service to their monopoly service.They aren't saying they can't use the patented technology, they are saying that they must pay for a license to use it. Big difference.
With three floors, those drops can get very long. Longer than GigE can run on inexpensive cable. With older homes, there is always trouble running new wire.
>... you shouldn't have a problem with pulling a few legs of CAT6 or "fibre".
I take it you don't actually live in a house, especially one with more than one floor? When you don't have a crawl space underneath, or an attic overhead, the only way to get the wire from place to place is rip out the wall, drill through the studs, and put the wall back up. Most people aren't going to do that if they can use another pair from the pre-installed phone wires. It certainly isn't "simple".
ISTR that some (most?) of the standalone CD-Recorders will only work with CD-Rs marked for Audio. I think it encoded on the blanks much like the max speed information that keeps you from trying to burn a 4x disk at 40x.
Have you considered a minimal hardware install version? Something that would run on less than up to date computers, such as Pentium 133's with 500MB and 16M RAM? Something akin to the RULE Project ( http://www.rule-project.org/ ) or VUM:Box ( http://www.vum.at/ ), where older computers can be repurposed to allow more people access to modern technology, without being forced to have the latest and greatest hardware.
> Some of those issues have been solved with advent of the Turbo/Object Pascal...
Some? More like nearly all. The only ones I saw that still looked valid were the Procedure Something(a : array[0..10] of integer); and the limit on set size (although Delphi has a much, much larger size limit, and handles the alphanumeric example just fine).
All of the others, including passing arrays of different sizes to a procedure/function, have been covered.
> Sometimes you need a hack, and Pascal's purpose in life it to prevent those convient little hacks.
Which is why I like it. It is readable and maintainable. I've done my share of those hacks (ever program in Echelon's Neuron C for a processor with 256 BYTES of memory total?) but inevitably I have to figure out just what I did when I go back and look at that code later (even with extensive comments).
In Pascal, you can still do some of those odd things, but you have to explicitely spell out what you are doing. Only in a very few instances is the code less readable than the C version (interpreting Windows API multi-z strings is one).
Yeah, it's more typing the Pascal way, but most people can't really parse things like a = ? b : c in their heads. (Yeah, a real geek thinks that way, sure, right - A real geek makes his life easier, not harder!)
Not all useful apps are hundreds of megs in size. Without knowing anything about the apps our company produces, or what they do, it is rather arrogant to presume anything about their usefulness. And from what I've been told (as I'm not the developer), the total image and icon size is in the megabyte, not kilobyte, range. I'd assume much more of that space is having to include images for every supported model and screen resolution rather then the icons. I chose the icon sizes above as an example just to show how seemingly arbitrary Apple is about changing everything from one model to the next. Why in the world go to a 58x58 icon when there is a 57x57 icon available? Is that extra 115 pixels going to make the app all that much more beautiful? Is it worth the extra work, times every single iOS developer in the world, to gain those 115 pixels? How many millions of man-hours of productivity world wide have been wasted recreating icon and image sets to deal with each and every change iOS makes to their screen? Large shops with hundreds of developers probably don't notice or care, but smaller developers certainly do.
> The high-resolution image assets that developers are required to add also contributes to the size of an app. -- This. Having to provide icons at 57x57 and 58x58, just for two examples out of dozens, is asinine. Our app code is dwarfed by the image collection size just to provide the minimum number of icons and load screens required.
Ubuntu + KDE = Kubuntu, Ubuntu + Xfce = Xubuntu. I run most of my laptops with Xubuntu, as it is much lighter weight resource-wise than full Ubuntu.
HP LaserJet III - Can't seem to kill it. Slow, by today's standards, but still prints like a champ. It's at home or I'd pull up the page stats. I think its over 1,000,000 prints, as it was used at the office for at least 15 years before they retired it (couldn't get a parallel port to run it off of easily) and I brought it home. HP 28C - While not everyone's favorite HP calculator, my 28C was purchased when I was a freshman in college in 1985, and still used daily. As a matter of fact, I think it's only on it's fourth or fifth set of batteries. They just never die.
In addition to the modem control signals, USB adapters also really mess up the timing of the signals. Some RS-232 hardware does not use any flow control, and relies on character timeouts to detect end of message. USB ports packetize the data, and can break up the packets in unpredictable places, so that delays can appear in the message, causing the other side to detect an end of message too soon. Also, some equipment uses the control lines such as RTS/CTS, DSR/DTR, RI, and DCD for I/O purposes. In DOS, it wasn't that hard to get somewhat decent timing to create and/or detect signals of specific duration with these pins, using them as essentially free digital I/O. With a USB to serial adapter, especially under Windows, it is nearly impossible to get any precision timing. Add to that another layer of VM, and it just gets worse. How bad this is really depends on the chipset and drivers. I've had more luck with PL2303 based devices than FTDI along these lines, but for some applications, USB to serial just won't work.
Well, the meanings of words change, anyway, but not always for the best. At best, I would have called this a biomechanical cat, not a bionic one, but I'm in my 40's, so new uses of old terms bothers me more than some.
Bionic = Biological + Electronic. Where's the electronic part of all this?
Absolutely not. Verizon can have all the patents they want, they just can't use them as a way to prevent another carrier from offering a competing service to their monopoly service.They aren't saying they can't use the patented technology, they are saying that they must pay for a license to use it. Big difference.
With three floors, those drops can get very long. Longer than GigE can run on inexpensive cable. With older homes, there is always trouble running new wire.
> ... you shouldn't have a problem with pulling a few legs of CAT6 or "fibre".
I take it you don't actually live in a house, especially one with more than one floor? When you don't have a crawl space underneath, or an attic overhead, the only way to get the wire from place to place is rip out the wall, drill through the studs, and put the wall back up. Most people aren't going to do that if they can use another pair from the pre-installed phone wires. It certainly isn't "simple".
Dunno. Maybe the smoking rooms?
ISTR that some (most?) of the standalone CD-Recorders will only work with CD-Rs marked for Audio. I think it encoded on the blanks much like the max speed information that keeps you from trying to burn a 4x disk at 40x.
Similar to the XPort and PicoTux. It seems to be more stable than the XPort.
For one, it has 256 colors instead of 16. None of the games support it, but your own code could.
Have you considered a minimal hardware install version? Something that would run on less than up to date computers, such as Pentium 133's with 500MB and 16M RAM? Something akin to the RULE Project ( http://www.rule-project.org/ ) or VUM:Box ( http://www.vum.at/ ), where older computers can be repurposed to allow more people access to modern technology, without being forced to have the latest and greatest hardware.
> Some of those issues have been solved with advent of the Turbo/Object Pascal... Some? More like nearly all. The only ones I saw that still looked valid were the Procedure Something(a : array[0..10] of integer); and the limit on set size (although Delphi has a much, much larger size limit, and handles the alphanumeric example just fine). All of the others, including passing arrays of different sizes to a procedure/function, have been covered.
Wow! I'd love to have one of these to add to my collection of obsolete computers!
> Sometimes you need a hack, and Pascal's purpose in life it to prevent those convient little hacks.
Which is why I like it. It is readable and maintainable. I've done my share of those hacks (ever program in Echelon's Neuron C for a processor with 256 BYTES of memory total?) but inevitably I have to figure out just what I did when I go back and look at that code later (even with extensive comments).
In Pascal, you can still do some of those odd things, but you have to explicitely spell out what you are doing. Only in a very few instances is the code less readable than the C version (interpreting Windows API multi-z strings is one).
Yeah, it's more typing the Pascal way, but most people can't really parse things like a = ? b : c in their heads. (Yeah, a real geek thinks that way, sure, right - A real geek makes his life easier, not harder!)
Search for files or folders named: *.* Containing text: password How is this any different?