First hook up all your equipment so that it doesn't go through ANY of the wiring in your house. Then do your testing. Once you are convinced that the problem exists in their equipment or outside your house then call them. They're supposed to only charge you for problems in your equipment or wiring. It's up to you to convince them of it! Basically if they come out and it's their problem then they don't charge you for the visit.
Mankind has come up with lots of ways to kill another person. The problem doesn't lie in the weapon used, they are just tools. The problem lies in the killer themselves.
If a baseball bat or knife was used, he might kill one person in a surprise attack. If an automatic weapon is used, he might kill 10 people in a surprise attack.
And if he threw some fertilizer and oil together he might kill a couple of hundred people (maybe even thousands) in a surprise attack. The point is that guns are not necessary to kill lots of people.
Jury: You don't get a choice in that one, you can't decide "I'll be on a jury today" and do so.
The jury part of that quote refers to using the judicial system, as in you can sue someone over the issue. Yes, serving on a jury would go towards that too but it's not the only action you can take.
Their only reason is to kill people. Just ban guns already.
...or to kill animals
Or even to prevent people from being killed. When you have someone hell-bent on killing people, maybe with a bomb or some other large-scale means, then using a gun to kill him could prevent the deaths of a lot of other people.
A gun is a tool. It is neither inherently good or bad. If there weren't any guns then people would find other ways to harm others - just like has happened for thousands of years in the past.
Not to mention that the genii is out of the bottle. There is a worldwide availability of guns that won't be stopped any time soon, if ever. Banning guns is just going to take them out of the hands of responsible people who could use them to defend themselves, not just against individuals but also against abusive governments.
It's very sad that there are sick individuals who misuse these tools to shoot innocent people but overall it's not going to help the majority of people to ban legal ownership of firearms.
Just complain loudly and often to your ISP and get someone out to check the line. When I had DSL it would go bad fairly often, I'd just complain and get someone to come out and fix the connection or they'd even re-run the line. DSL can be very finicky, especially at the connections. They are using better connectors now that have a sealing agent but they still go bad every so often. When that happens the connections can oxidize or moisture can get into the lines and cause problems.
These problems also might only show up when conditions are right. Winds, rain, cold, heat, a tree rubbing against the line, all sorts of things can make the problems tough to diagnose. That's why it's important to get a person out to check the line rather than them just remotely checking the modem. Like I said, complain EVERY time the problem comes up and you have the best chance of them catching it and sending a tech out.
The only problem is extreme latency and jitter when the connection is saturated (even with a single HTTP download). The other things you mention would cause reduced throughput and increased packet loss. This is an entirely wired connection, by the way: DSL and Ethernet only.
If they were using large buffers you'd usually see less jitter, not more. Large buffers generally cause large, consistent latency if they are not properly managed. I'm not ruling it out completely but I'd say the problem lies with the DSL connection. They are notoriously finicky and exhibit these kinds of behaviors when the connection is borderline. DSL is very vulnerable to outside interference, that's where my bet lies.
New cell towers, changed placement of power lines, cordless phone interference, connectors that have gotten old or allowed moisture to seep in, those are just a few problems that can cause degraded DSL performance. DSL is fairly adaptive and a line can be operational but still offer sub-optimal performance.
I was a Mac user until recently, and an Apple II user before I started with Macs. But lately, I just absolutely refuse to use anything with their brand on it because of this precise behavior.
What behavior? Apple clearly stated their terms for the use of the service. The VLC media player developers use a license which is not compatible with those terms. In fact, it was those developers who took the first action:
Today, a formal notification of copyright infringement was sent to Apple Inc. regarding distribution of the VLC media player for iPad, iPhone and iPod Touch.
Apple simply complied with the notification and took down the app in question. If the developers want their software in Apple's App Store then they should release it under a compatible license. I'm sure they can (and perhaps they have) also try to convince Apple to change the terms of the app store.
Every store has to have rules or it'd be complete anarchy. Sometimes these rules are going to get in the way of someone's idea of how it should all work. This is one of those times. Obviously Apple's rules work for a lot of cases since there are tons of apps, both good and bad, in the app store. There's nothing evil going on here, it's just two entities enforcing the terms of use for their properties.
My best guess is that at some point the AT&T equipment here was changed and the buffers got much bigger.
You can't reasonably come to that conclusion without more data. There's a slew of other things that could have gone wrong such as a bad connector causing noise somewhere down the line, a malfunctioning router, interference from some other source, misconfigured equipment, and so on. A badly implemented buffer is just one of many possible problems.
The issue is that, when packets are dropped and the TCP window narrows, it's pretty much a catastrophe from throughput perspective. In particular, the recipient won't know about a dropped packet until the latency delay, and the sender won't know about it until (minimum) twice that latency.
I'm a computer science major, not a network engineer.
It's been a bit since I've closely studied TCP/IP but I believe what is proper is for the router to participate in the congestion control through notifications and randomly dropping packets early based on a computed probability that the buffer will eventually begin doing tail drops, among other techniques. A good router will try to prevent the buffer from ever getting too full or too empty in the first place through these methods. It shouldn't ever get to the point where there's a dropped packet that belongs at the end of a large buffer.
Of course I'm sure there are plenty of poorly-implemented flow control mechanisms out there that are wreaking all sorts of havoc. A huge buffer will certainly exacerbate a poor network congestion algorithm. Buffers are generally intended to reduce jitter and they can definitely introduce latency in a bad scenario such as this.
As an extreme example, say you request a 1GB file from a download site. That site has a monster internet connection, and manages to transmit the entire file in 1 second. The file makes it to the ISP at that speed, who then buffers the packets for slow transmission over your ADSL link, which will take 1 hour. During that time you try to browse the web, and your PC tries to do a dns lookup. The request goes out ok, but the response gets added to the buffer on the ISP side of your internet connection, so you won't get it until your original transfer completes. How's 1 hour for latency?
This is an example of how NOT to implement a buffering system. Ideally you should have multiple buffers per connection and have TCP streams go to an available buffer. You then service the buffers according to some scheduling algorithm, reading from one buffer for a pre-determined amount and then switching to another. In this way you can have a large download buffered but if a small stream opens it isn't too burdened by the buffer of the large stream.
You just need a couple of buffers per connection in order to provide a balance between reducing latency and avoiding starvation.
This is a huge topic and a lot of these problems have already been worked out. Some compromises have been made and sometimes there are unintended consequences or bad assumptions but overall it does work pretty well.
If we all switched to ATM (Asynchronous transfer mode), would this issue be fixed, regardless of the size of RAM available at the endpoints?
A good buffering algorithm SHOULD be implemented as a fifo queue, preferably a circular buffer. Nothing should stop transmitting in order to fill up the buffer, the front of the queue should be emptied as fast as possible and the back of the queue should be filled as fast as possible. Stopping to fill a buffer before transmitting is just asinine.
Buffers should work to even out transfer speeds and reduce jitter. What will happen is that a buffer just before the slowest link will start to fill as more data comes in than goes out. Once the buffer is full the packets will begin to be dropped and the TCP window will narrow, in the meantime the buffer should still continue to serve the slower link data. Ideally the transmission rate will balance out such that the buffer stays partially filled the entire time, in the real world there will always be some jitter but a properly-implemented buffer shouldn't make it much worse and should have the potential to greatly improve it.
This is not something that well written apps do, but pretty much what every app does. Those that don't automatically recreate preference files would be a rare exception.
Right, I was referring to other types of files such as stuff that gets placed in/Library/Application Support and ~/Library/Application Support. There are also fonts, kernel extensions, preference panes, and so on. A well-written application should detect that those are missing (or damaged) and attempt to replace them when it is run.
Of course all of those will still hang around if you just move the application package so programs that install those sorts of items should provide the user with a method of doing a complete uninstall and inform the user about it. This goes for any operating system really.
That's why I prefer using.pkg files (installer packages) for installing rather than the Apple-recommended.dmg files (disk image files). With.pkg installers you can use pkgutil to see exactly what was modified or installed. The installer packages also usually have an uninstall script which cleanly removes all traces of the application. As a developer I almost always distribute my applications as installer packages rather than disk image files for this very reason.
Apologies for replying to myself, but it'd be useful if someone could post the USD prices for comparison - see if they're trying to implement regional price differences (over and above the necessary exchange rate + taxes) or not.
Apple's flagship photo-editing software, Aperture, is in the store for just $80. You can still buy it from the conventional Apple Store, but it'll cost the usual $200.
The three iWork apps, Pages, Numbers and Keynote, cost $20 apiece, a saving on the usual $80 bundle price.
Really? Is that why I can move my home directory from one linux install to another and the programs will still run?
I believe he's just talking about your application directory, not your entire home directory.
Really, it completely depends on the software. Mac OS apps tend to be packages, basically directories with a pre-defined structure and extension that the GUI treats as a file instead of as a directory. You can still open them like a directory through a special command but when you use the normal open/run command they run like an application. Since the entire application is a directory it contains pretty much everything that it needs to run and you can simply move the package anywhere you need it to be, even to another computer.
Now some applications do create a preference file and some support files that are located elsewhere on the computer so sometimes there is stuff left behind. The well-written applications will simply re-create these files if they need them and they don't exist. This often means that when you move it to a new computer then the moved application might start in a default state if you don't also move the preference or support files.
Some Linux applications work in a similar manner, although others are more liberal where they spread their components. One of the key things is shared libraries, on Mac OS a developer is supposed to include the libraries not part of the base OS install in the package. On Linux they are often installed in a different location than the application and when you move the application you are supposed to also copy or re-install the libraries. It's not quite as automatic, hence the emphasis on packaging systems on Linux systems. On Linux it's usually just easier to install your applications through a package system than move them.
In Battlefield I am not doing the same stuff over and over again. I am fighting against live players. They are always doing something different and I'm always reacting to the dynamic environment we players create.
Play it long enough and you end up doing the same stuff over and over again. There's only so many different ways you can assault a base or defend an area. Even when people come up with different maps there's only so many different scenarios that can be created. Eventually even a good FPS with lots of interesting maps becomes repetitive.
The trick is to just give good value for the money. If you build a good system that allows for a lot of creativity without too much complexity then the players will be able to play for enough time to make the game worth it. This goes even more for a subscription service, if you can refresh things and keep it interesting then people will be happy to plunk down the subscription fee. It really doesn't matter if it is PVP or PVE, although PVP tends to stay fresh a while longer since there are usually more players being creative than developers creatively building environment.
I was curious about this...particularly what it means to "reverse the polarity of a swimming pool"... um, I didn't know they had poles:) (clearly something to do with the wiring...)
It's a pretty simple concept. Swimming pools are usually grounded (electrically connected to a large sink for electrical charge) in order to ensure that all electricity drains away from the pool and the occupants. This is done for lightning strikes as well as stuff accidentally falling in the water and lights, pumps and other equipment shorting out.
Reversing the polarity would be to remove the ground wire from the ground and instead connecting it to a high voltage source. Now the water is live and can electrocute someone who jumps in. It's simple in theory but in practice tough to accomplish. There are all sorts of ways that people are protected from shorts, from ground fault interrupters to fusible links to circuit breakers. You'd most likely have to do a lot more than just swap two wires to ensure that a pool is deadly.
I have a Samsung ML-1740 laser printer. It's cheap, is no longer sold, but it works fine as long as you can print to it. My niece's linux laptop was able to print to it immediately, but Snow Leopard balked at it and I can't actually print to it anymore from my machine. Perhaps if I knew more about printing it would be trivial to write my own driver or install a third party driver that actually works with that model of printer.
Try the driver for the Samsung ML-1710 printer. I hear that it mostly works for the Samsung ML-1740 with only a few minor glitches. You can also give this driver package a try.
I have never gotten my Airport Extreme to share printers via its USB port properly. They'll print once or twice and then crap out and need to be restarted. I haven't determined if this is a property of the HP printers that are causing this issue or if it's something related to the Airport.
I've seen this problem with a couple of HP printers in various situations. I think it has something to do with their USB ports. Occasionally I have to disconnect them and reconnect them and then they work. It's an odd bug for sure.
The phone never had a problem keeping time. The bugs were in the calendar / alarm apps which didn't come to terms with the fact that time may change slightly, and not with the underlying timekeeping code.
Well, the proper way to handle this is to use NSDate and NSCalendar along with the Event Kit Framework. If you use these classes then they should handle all of the time changes for you, rolling your own code to do this is definitely not a good idea because there are so many issues with time changes and calendar idiosyncrasies.
Basically it comes down to either the apps in question are doing the calculations on their own and there are errors in those calculations or the frameworks themselves have these bugs. I think it's likely that the bugs are in the frameworks because Apple is usually pretty good about using the proper frameworks rather than taking shortcuts.
By the way, here's an excellent write-up of some of the issues as well as examples of how to do these calculations in an iOS app.
As some people have pointed out testing cases for timing applications including the end of the year is programming QA 101. I would just chuckle if this was the first time this has happened. But this is the second time a major bug has screwed around iPhone users in the alarm application. It stuffed up daylight savings time too, which makes me think if they didn't review the code then, what's going to happen on Feb 29th? The question is will they actually review the entire code this time or just patch this flaw.
As a programmer I can tell you that date and time calculations are among the most tricky ones that you have to do. It's so easy to get wrong with leap times (days, minutes, seconds, fractions of a second), time zones, local time adjustments, changing rules on how dates and times are calculated, various calendars, and so on. It's very easy for a tricky bug to get coded into the algorithms and to have it suddenly show up without much time to correct it.
Not that bugs, especially core ones in date and time functions, are acceptable. You do everything you can do to test the code and ferret them out. It's just one of those areas that bugs are likely since so many tricky rules are involved. I'm sure that Apple will try to locate the code that causes this bug and correct it. Hopefully that will be the end of the problems.
I agree that the Android SMS bug is also a bad flaw in a major function of a cell phone. Again, I'm sure that Android developers will do their best to correct it.
The fact is that modern computing devices are extremely complicated systems with tons of interacting components, many different developers, and plenty of potential for unintended side effects. You take your chances when you use such devices and it's up to each person to decide if they can live with any issues that pop up or if they want to take the chance on a different device. I've had a decent enough experience with the iOS devices that I can live with the bugs that have popped up so far, I don't think that it has that much higher or lower of a rate of bugs than similar devices by other developers.
Their earlier iPhone was great, and their new iPhone's glassy facade gives me a woody every time I see it. But there seems to be one critical problem after another with this one.
Personally I think it's mostly the media having a field day blowing things out of proportion. I have the new iPhone, both my sisters have one, my brother-in-law has one and none of us have had anywhere near the problems that are being reported in the media. Sure, there's been a few minor glitches here and there but nearly EVERY device has those. We certainly haven't experienced any problems that were major enough to stop us from using the iPhone or consider switching to another device.
I mean lets forget about fucked up blue tooth support, not being able to send vcards (as i have done from small device to small device since my first palm/mobile phone), and lets just accept that automatic configuration (which worked for me in all courntries i have been in recently) is a little bit complicated for a phone for approx. 500Euro). Lets also forget that video calls follow just apples standard.
But what really disappointed me in this incredibly immature device is that under certain conditions EDGE support from the mobile cell tower prevents making calls on the iphone (my nokia works fine at the same conditions).
How is bluetooth support "fucked up"? I've never had a problem connecting to devices and it seems to work just the same as any other phone I've used.
You can't send vcards? I'm able to send them via MMS and e-mail without a glitch, I do it all the time.
FaceTime hardly follows just Apple's standards. It's using a ton of open standards such as H.264, AAC, and many more. Now, the entire process of establishing and maintaining a FaceTime connection is fairly complex and Apple has said that they will open the technology up to others at some point in the future, just as iTunes and the iPod used to be Mac-only but were eventually opened up to the Windows world.
I don't know what problem you are having with EDGE but I have unlocked an iPhone to run on another provider and so far there's been no unusual problems. Do you have any data on what these "certain conditions" are? Have you reported them to your provider? Perhaps the signal is out of spec in some way that the Nokia ignores but the iPhone doesn't, it's not always the right thing to make a connection when the signal is out of spec.
Slashdot Mirror
First hook up all your equipment so that it doesn't go through ANY of the wiring in your house. Then do your testing. Once you are convinced that the problem exists in their equipment or outside your house then call them. They're supposed to only charge you for problems in your equipment or wiring. It's up to you to convince them of it! Basically if they come out and it's their problem then they don't charge you for the visit.
At least he had arguments, you just have swearing. What do you call that, "Proof by potty-mouthing"?
Don't feed the trolls, especially the anonymous coward ones! ;-)
Bow and arrow, spear, thrown dagger, rock.
Not to mention:
and even less direct means:
Mankind has come up with lots of ways to kill another person. The problem doesn't lie in the weapon used, they are just tools. The problem lies in the killer themselves.
If a baseball bat or knife was used, he might kill one person in a surprise attack. If an automatic weapon is used, he might kill 10 people in a surprise attack.
And if he threw some fertilizer and oil together he might kill a couple of hundred people (maybe even thousands) in a surprise attack. The point is that guns are not necessary to kill lots of people.
Jury: You don't get a choice in that one, you can't decide "I'll be on a jury today" and do so.
The jury part of that quote refers to using the judicial system, as in you can sue someone over the issue. Yes, serving on a jury would go towards that too but it's not the only action you can take.
Their only reason is to kill people. Just ban guns already.
...or to kill animals
Or even to prevent people from being killed. When you have someone hell-bent on killing people, maybe with a bomb or some other large-scale means, then using a gun to kill him could prevent the deaths of a lot of other people.
A gun is a tool. It is neither inherently good or bad. If there weren't any guns then people would find other ways to harm others - just like has happened for thousands of years in the past.
Not to mention that the genii is out of the bottle. There is a worldwide availability of guns that won't be stopped any time soon, if ever. Banning guns is just going to take them out of the hands of responsible people who could use them to defend themselves, not just against individuals but also against abusive governments.
It's very sad that there are sick individuals who misuse these tools to shoot innocent people but overall it's not going to help the majority of people to ban legal ownership of firearms.
Just complain loudly and often to your ISP and get someone out to check the line. When I had DSL it would go bad fairly often, I'd just complain and get someone to come out and fix the connection or they'd even re-run the line. DSL can be very finicky, especially at the connections. They are using better connectors now that have a sealing agent but they still go bad every so often. When that happens the connections can oxidize or moisture can get into the lines and cause problems.
These problems also might only show up when conditions are right. Winds, rain, cold, heat, a tree rubbing against the line, all sorts of things can make the problems tough to diagnose. That's why it's important to get a person out to check the line rather than them just remotely checking the modem. Like I said, complain EVERY time the problem comes up and you have the best chance of them catching it and sending a tech out.
The only problem is extreme latency and jitter when the connection is saturated (even with a single HTTP download). The other things you mention would cause reduced throughput and increased packet loss. This is an entirely wired connection, by the way: DSL and Ethernet only.
If they were using large buffers you'd usually see less jitter, not more. Large buffers generally cause large, consistent latency if they are not properly managed. I'm not ruling it out completely but I'd say the problem lies with the DSL connection. They are notoriously finicky and exhibit these kinds of behaviors when the connection is borderline. DSL is very vulnerable to outside interference, that's where my bet lies.
New cell towers, changed placement of power lines, cordless phone interference, connectors that have gotten old or allowed moisture to seep in, those are just a few problems that can cause degraded DSL performance. DSL is fairly adaptive and a line can be operational but still offer sub-optimal performance.
I was a Mac user until recently, and an Apple II user before I started with Macs. But lately, I just absolutely refuse to use anything with their brand on it because of this precise behavior.
What behavior? Apple clearly stated their terms for the use of the service. The VLC media player developers use a license which is not compatible with those terms. In fact, it was those developers who took the first action:
Today, a formal notification of copyright infringement was sent to Apple Inc. regarding distribution of the VLC media player for iPad, iPhone and iPod Touch.
Apple simply complied with the notification and took down the app in question. If the developers want their software in Apple's App Store then they should release it under a compatible license. I'm sure they can (and perhaps they have) also try to convince Apple to change the terms of the app store.
Every store has to have rules or it'd be complete anarchy. Sometimes these rules are going to get in the way of someone's idea of how it should all work. This is one of those times. Obviously Apple's rules work for a lot of cases since there are tons of apps, both good and bad, in the app store. There's nothing evil going on here, it's just two entities enforcing the terms of use for their properties.
My best guess is that at some point the AT&T equipment here was changed and the buffers got much bigger.
You can't reasonably come to that conclusion without more data. There's a slew of other things that could have gone wrong such as a bad connector causing noise somewhere down the line, a malfunctioning router, interference from some other source, misconfigured equipment, and so on. A badly implemented buffer is just one of many possible problems.
... how do I address this 'SMS of death' message to all the phones in my immediate vicinity?
Use a cell broadcast!
The issue is that, when packets are dropped and the TCP window narrows, it's pretty much a catastrophe from throughput perspective. In particular, the recipient won't know about a dropped packet until the latency delay, and the sender won't know about it until (minimum) twice that latency.
I'm a computer science major, not a network engineer.
It's been a bit since I've closely studied TCP/IP but I believe what is proper is for the router to participate in the congestion control through notifications and randomly dropping packets early based on a computed probability that the buffer will eventually begin doing tail drops, among other techniques. A good router will try to prevent the buffer from ever getting too full or too empty in the first place through these methods. It shouldn't ever get to the point where there's a dropped packet that belongs at the end of a large buffer.
Of course I'm sure there are plenty of poorly-implemented flow control mechanisms out there that are wreaking all sorts of havoc. A huge buffer will certainly exacerbate a poor network congestion algorithm. Buffers are generally intended to reduce jitter and they can definitely introduce latency in a bad scenario such as this.
As an extreme example, say you request a 1GB file from a download site. That site has a monster internet connection, and manages to transmit the entire file in 1 second. The file makes it to the ISP at that speed, who then buffers the packets for slow transmission over your ADSL link, which will take 1 hour. During that time you try to browse the web, and your PC tries to do a dns lookup. The request goes out ok, but the response gets added to the buffer on the ISP side of your internet connection, so you won't get it until your original transfer completes. How's 1 hour for latency?
This is an example of how NOT to implement a buffering system. Ideally you should have multiple buffers per connection and have TCP streams go to an available buffer. You then service the buffers according to some scheduling algorithm, reading from one buffer for a pre-determined amount and then switching to another. In this way you can have a large download buffered but if a small stream opens it isn't too burdened by the buffer of the large stream.
You just need a couple of buffers per connection in order to provide a balance between reducing latency and avoiding starvation.
This is a huge topic and a lot of these problems have already been worked out. Some compromises have been made and sometimes there are unintended consequences or bad assumptions but overall it does work pretty well.
If we all switched to ATM (Asynchronous transfer mode), would this issue be fixed, regardless of the size of RAM available at the endpoints?
A good buffering algorithm SHOULD be implemented as a fifo queue, preferably a circular buffer. Nothing should stop transmitting in order to fill up the buffer, the front of the queue should be emptied as fast as possible and the back of the queue should be filled as fast as possible. Stopping to fill a buffer before transmitting is just asinine.
Buffers should work to even out transfer speeds and reduce jitter. What will happen is that a buffer just before the slowest link will start to fill as more data comes in than goes out. Once the buffer is full the packets will begin to be dropped and the TCP window will narrow, in the meantime the buffer should still continue to serve the slower link data. Ideally the transmission rate will balance out such that the buffer stays partially filled the entire time, in the real world there will always be some jitter but a properly-implemented buffer shouldn't make it much worse and should have the potential to greatly improve it.
This is not something that well written apps do, but pretty much what every app does. Those that don't automatically recreate preference files would be a rare exception.
Right, I was referring to other types of files such as stuff that gets placed in /Library/Application Support and ~/Library/Application Support. There are also fonts, kernel extensions, preference panes, and so on. A well-written application should detect that those are missing (or damaged) and attempt to replace them when it is run.
Of course all of those will still hang around if you just move the application package so programs that install those sorts of items should provide the user with a method of doing a complete uninstall and inform the user about it. This goes for any operating system really.
That's why I prefer using .pkg files (installer packages) for installing rather than the Apple-recommended .dmg files (disk image files). With .pkg installers you can use pkgutil to see exactly what was modified or installed. The installer packages also usually have an uninstall script which cleanly removes all traces of the application. As a developer I almost always distribute my applications as installer packages rather than disk image files for this very reason.
Apologies for replying to myself, but it'd be useful if someone could post the USD prices for comparison - see if they're trying to implement regional price differences (over and above the necessary exchange rate + taxes) or not.
Take a look at this article:
Mac App Store Launches with 1,000 Apps, Big Discounts
Apple's flagship photo-editing software, Aperture, is in the store for just $80. You can still buy it from the conventional Apple Store, but it'll cost the usual $200.
The three iWork apps, Pages, Numbers and Keynote, cost $20 apiece, a saving on the usual $80 bundle price.
Really? Is that why I can move my home directory from one linux install to another and the programs will still run?
I believe he's just talking about your application directory, not your entire home directory.
Really, it completely depends on the software. Mac OS apps tend to be packages, basically directories with a pre-defined structure and extension that the GUI treats as a file instead of as a directory. You can still open them like a directory through a special command but when you use the normal open/run command they run like an application. Since the entire application is a directory it contains pretty much everything that it needs to run and you can simply move the package anywhere you need it to be, even to another computer.
Now some applications do create a preference file and some support files that are located elsewhere on the computer so sometimes there is stuff left behind. The well-written applications will simply re-create these files if they need them and they don't exist. This often means that when you move it to a new computer then the moved application might start in a default state if you don't also move the preference or support files.
Some Linux applications work in a similar manner, although others are more liberal where they spread their components. One of the key things is shared libraries, on Mac OS a developer is supposed to include the libraries not part of the base OS install in the package. On Linux they are often installed in a different location than the application and when you move the application you are supposed to also copy or re-install the libraries. It's not quite as automatic, hence the emphasis on packaging systems on Linux systems. On Linux it's usually just easier to install your applications through a package system than move them.
In Battlefield I am not doing the same stuff over and over again. I am fighting against live players. They are always doing something different and I'm always reacting to the dynamic environment we players create.
Play it long enough and you end up doing the same stuff over and over again. There's only so many different ways you can assault a base or defend an area. Even when people come up with different maps there's only so many different scenarios that can be created. Eventually even a good FPS with lots of interesting maps becomes repetitive.
The trick is to just give good value for the money. If you build a good system that allows for a lot of creativity without too much complexity then the players will be able to play for enough time to make the game worth it. This goes even more for a subscription service, if you can refresh things and keep it interesting then people will be happy to plunk down the subscription fee. It really doesn't matter if it is PVP or PVE, although PVP tends to stay fresh a while longer since there are usually more players being creative than developers creatively building environment.
I was curious about this...particularly what it means to "reverse the polarity of a swimming pool"... um, I didn't know they had poles :) (clearly something to do with the wiring...)
It's a pretty simple concept. Swimming pools are usually grounded (electrically connected to a large sink for electrical charge) in order to ensure that all electricity drains away from the pool and the occupants. This is done for lightning strikes as well as stuff accidentally falling in the water and lights, pumps and other equipment shorting out.
Reversing the polarity would be to remove the ground wire from the ground and instead connecting it to a high voltage source. Now the water is live and can electrocute someone who jumps in. It's simple in theory but in practice tough to accomplish. There are all sorts of ways that people are protected from shorts, from ground fault interrupters to fusible links to circuit breakers. You'd most likely have to do a lot more than just swap two wires to ensure that a pool is deadly.
I have a Samsung ML-1740 laser printer. It's cheap, is no longer sold, but it works fine as long as you can print to it. My niece's linux laptop was able to print to it immediately, but Snow Leopard balked at it and I can't actually print to it anymore from my machine. Perhaps if I knew more about printing it would be trivial to write my own driver or install a third party driver that actually works with that model of printer.
Try the driver for the Samsung ML-1710 printer. I hear that it mostly works for the Samsung ML-1740 with only a few minor glitches. You can also give this driver package a try.
I have never gotten my Airport Extreme to share printers via its USB port properly. They'll print once or twice and then crap out and need to be restarted. I haven't determined if this is a property of the HP printers that are causing this issue or if it's something related to the Airport.
I've seen this problem with a couple of HP printers in various situations. I think it has something to do with their USB ports. Occasionally I have to disconnect them and reconnect them and then they work. It's an odd bug for sure.
Note that MS owns a big slice of the Apple pie.
You sure about that?
"Microsoft confirmed that it sold all of its AAPL holdings some time ago"
The phone never had a problem keeping time. The bugs were in the calendar / alarm apps which didn't come to terms with the fact that time may change slightly, and not with the underlying timekeeping code.
Well, the proper way to handle this is to use NSDate and NSCalendar along with the Event Kit Framework. If you use these classes then they should handle all of the time changes for you, rolling your own code to do this is definitely not a good idea because there are so many issues with time changes and calendar idiosyncrasies.
Basically it comes down to either the apps in question are doing the calculations on their own and there are errors in those calculations or the frameworks themselves have these bugs. I think it's likely that the bugs are in the frameworks because Apple is usually pretty good about using the proper frameworks rather than taking shortcuts.
By the way, here's an excellent write-up of some of the issues as well as examples of how to do these calculations in an iOS app.
As some people have pointed out testing cases for timing applications including the end of the year is programming QA 101. I would just chuckle if this was the first time this has happened. But this is the second time a major bug has screwed around iPhone users in the alarm application. It stuffed up daylight savings time too, which makes me think if they didn't review the code then, what's going to happen on Feb 29th? The question is will they actually review the entire code this time or just patch this flaw.
As a programmer I can tell you that date and time calculations are among the most tricky ones that you have to do. It's so easy to get wrong with leap times (days, minutes, seconds, fractions of a second), time zones, local time adjustments, changing rules on how dates and times are calculated, various calendars, and so on. It's very easy for a tricky bug to get coded into the algorithms and to have it suddenly show up without much time to correct it.
Not that bugs, especially core ones in date and time functions, are acceptable. You do everything you can do to test the code and ferret them out. It's just one of those areas that bugs are likely since so many tricky rules are involved. I'm sure that Apple will try to locate the code that causes this bug and correct it. Hopefully that will be the end of the problems.
I agree that the Android SMS bug is also a bad flaw in a major function of a cell phone. Again, I'm sure that Android developers will do their best to correct it.
The fact is that modern computing devices are extremely complicated systems with tons of interacting components, many different developers, and plenty of potential for unintended side effects. You take your chances when you use such devices and it's up to each person to decide if they can live with any issues that pop up or if they want to take the chance on a different device. I've had a decent enough experience with the iOS devices that I can live with the bugs that have popped up so far, I don't think that it has that much higher or lower of a rate of bugs than similar devices by other developers.
Their earlier iPhone was great, and their new iPhone's glassy facade gives me a woody every time I see it. But there seems to be one critical problem after another with this one.
Personally I think it's mostly the media having a field day blowing things out of proportion. I have the new iPhone, both my sisters have one, my brother-in-law has one and none of us have had anywhere near the problems that are being reported in the media. Sure, there's been a few minor glitches here and there but nearly EVERY device has those. We certainly haven't experienced any problems that were major enough to stop us from using the iPhone or consider switching to another device.
I mean lets forget about fucked up blue tooth support, not being able to send vcards (as i have done from small device to small device since my first palm/mobile phone), and lets just accept that automatic configuration (which worked for me in all courntries i have been in recently) is a little bit complicated for a phone for approx. 500Euro). Lets also forget that video calls follow just apples standard.
But what really disappointed me in this incredibly immature device is that under certain conditions EDGE support from the mobile cell tower prevents making calls on the iphone (my nokia works fine at the same conditions).
How is bluetooth support "fucked up"? I've never had a problem connecting to devices and it seems to work just the same as any other phone I've used.
You can't send vcards? I'm able to send them via MMS and e-mail without a glitch, I do it all the time.
FaceTime hardly follows just Apple's standards. It's using a ton of open standards such as H.264, AAC, and many more. Now, the entire process of establishing and maintaining a FaceTime connection is fairly complex and Apple has said that they will open the technology up to others at some point in the future, just as iTunes and the iPod used to be Mac-only but were eventually opened up to the Windows world.
I don't know what problem you are having with EDGE but I have unlocked an iPhone to run on another provider and so far there's been no unusual problems. Do you have any data on what these "certain conditions" are? Have you reported them to your provider? Perhaps the signal is out of spec in some way that the Nokia ignores but the iPhone doesn't, it's not always the right thing to make a connection when the signal is out of spec.