it probably didn't feed into the computer directly but that was pretty much it.
Oh, but it probably did. The Altair 8800 wasn't the only computer to use that interface; it was simply the most well known.
Programming the Altair was an extremely tedious process. The user toggled the switches to positions corresponding to the desired 8080 microprocessor instruction or opcode in binary, then used the 'DEPOSIT NEXT' switch to load that instruction into the next address of the machine's memory. They repeated this step until all the opcodes of a presumably complete and correct program were in place.
did anyone ever do anything substantial in bit strings?
If you don't think inputting the code that allowed keyboard input (and printing or monitor display) of those hex values is substantial, then no. There was a time when computer interfaces were simply a series of switches; set your byte, then literally push it (with a button) to the stack. Everything we have today was built from that so, yes, I'd say that's substantial.
What I can do, hiwever, is power dual 5k displays with Thunderbolt 3, which happens to share a port with USB-C. Incidentally, that's what Apple does, as well; the difference being that I can do it with a higher-end GPU than Apple is willing to sell me, thereby putting less stress on my GPU and ensuring it lasts longer. Heat is a component killer.
Supposedly, the data doesn't leave the phone; COPPA should not apply. That they spefically chose the age limit for COPPA tells me they believe it does apply and, since Apple's lawyers aren't likely to be idiots, that tells me the data probsbly leaves the phone.
Push is a synchronization method, as is pull. In fact, they're kind of the only two... you're either pulling data when you want it or having it pushed to you periodically or as it changes. There are a great many variations on that and they're sometimes combined (as in my example, above), but they're the only two methods. You are either requesting data (pull) or having it handed to you (push), how else would it get there?
If push is implemented properly, you register with the service and get fresh data at that time; then you get updates every time the data changes. Your data is never out of date (as long as you remain connected) with proper push. And if you lose connection at some point, well, a refresh button wouldn't work either.
The most common issue with pushing data is that developers will forget that they need to track their connectivity and re-register if connectivity has been lost for any period of time. That, of course, is not properly implemented.
Helo flies lower than is advisable hits a drone flying higher than is advisable then lands safely. Drone is obliterated. Clearly the drone is at fault?
No, but the operator of the drone is.
Injury or death does not absolve one of fault. If you step in front of a speeding car and get hurt or killed, you're still at fault for having stepped in front of the car.
Of course, the driver of the car is also at fault, as they were speeding. But, someone else being in the wrong too does not absolve you of responsbility; it's called shared responsibility. If the helo pilot was flying where he shouldn't have been, he is at fault; if the drone pilot was flying where he shouldn't have been, he is also at fault. If either of them had not fucked up, the incident would have been avoided. It took both of them fucking up in order for the incident to occur, therefore, they are both at fault.
I've really fucking had it with this "the thing I did wrong is okay because they did something wrong, too" mentality that seems to be running rampant lately. Seriously, it doesn't even make sense because the other person could just turn around and say the same thing; what they did wrong was okay because you did something wong. Okay, fine, neither of you take responsibility for whatever happened, and just both deal with the your own consequences of the resulting events separately. Don't want to do that? Both own up to your responsibility for the incident and deal with each others' consequences instead; after all it was your fuck up that caused those consequences for the other person -- even if their fuck up caused consequences for you.
It happens all too often. Bikes riding on the road are a perfect example. If a cyclist is obeying traffic laws and gets hit, it's the driver's fault; but, many cyclists think they're somehow absolved of the responsibility to obey the law.
as a result, most accidents involving cyclists are, in the best case for the cyclist, shared responsibility. There was one guy who I swear was trying to get me to hit him every morning on my way to work. I didn't matter how early or how late I left, there he was, and he'd come from 100ft back or so as soon as he saw me and blow through his stop sign as I (who had no stop sign) began my right turn, turning left in front of me. Had I, one day, not stopped in time to avoid him (and there were a few close calls), it would have been not just because I fucked up, but also because he failed to stop as required by law; had either of us not fucked up, there would have been no accident. He consistently (seemingly purposely) fucked up and he's just lucky that I never did. The consequences for him would have been much worse than for me. One day, there was a bike pedal on the ground at that intersection and I never saw him again -- he must have tried that shit with a less skilled driver. Oops.
And that brings us back to personal responsibility. That cyclist was responsible for his own safety and obeying the law was just the first part of that. Awareness and avoidance are other parts (and there are a few more that are activity-specific) at which he clearly failed. When the potential consequences of someone fucking up (not necessarily you) are worse for you than they are for the other person, you have a personal responsibility -- for your own safety -- to observe and avoid, even if they're the one who's wrong. Take the cyclist; I wasn't there when he (presumably) got hit, maybe he did stop at the sign, maybe whoever 9presumably) hit himwaved him on, then gunned it and mowed him down. In that case, the driver is at fault for setting the incident up; but the cyclist failed to observe the driver, who was a known danger to the cyclist, and avoid the incident. As a result, the cyclist (presumably) was severely injured or killed.
Of course they do; they actually believed things would be better under Trump. A handful of us realized we were screwed either way; yes, we're also butthurt, but for different reasons.
Injuries from clamshell packaging are the result of idiots opening said packaging in idiotic ways and results only in injury to themselves. An collision between two aircraft is the result of idiots flying where they shouldn't and results in injury to others.
Please, don't be the inconsiderate prick that can't see how one idiot injuring someone else is worse than thousands of idiots injuring themselves. You can prevent self-injury by not being an idiot, but that doesn't save you from idiots (and you can't make someone else not be an idiot). If this were a story about idiots crashing their drones into their own heads, nobody would be calling them out for airspace violations; instead, we'd be calling them idiots, because that's what they are.
Mind you, everyone screaming that we need more regulation of airspace is an idiot, as well. Airspace is plenty-well regulated, but we do need better enforcement of those regulations. When people stop getting away with violations, we'll see fewer of them.
No, my point is that the poster posted a bunch of innuendo and tried to make it look like we had a credible report of a drone causing a fatality from Australia when what we actually had was a not so near miss, a bat strike, and Australia reporting that Germany reported that a very large conventional RC airplane once caused a motor glider fatality back in 1999.
Actually, the claim was never made that it happened in Australia. Furthermore, where it happened doesn't really much matter; a 10kg object would have taken down that manned aircraft anywhere in the world. In fact, as that glider was open-cockpit, a drone weighing a few ounces could have potentially brought it down by knocking the pilot unconscious.
Keep in mind that we're not discussing planes vs drones; we're discussing manned aircraft vs unmanned aircraft.
Also, guys, over here! I've spotted the irresponsible douchenugget who's giving all model aircraft operators a bad name!
Which of the 5 mentioned in the report was that? And do you really think a 2.25kg drone will do any less damage when 2.25kg ducks, which are much softer, have been known to take down planes?
Was your point really "well, it hasn't happened in Austrailia, so it must not be a big deal"? And 5lb is still quite small for a drone capable of stable flight at altitudes over 100 feet or so; 20lb (that is, ~10kg) drones fare much better than their lighter "toy" counterparts at higher altitudes where there are likely to be stronger winds. You'd me amazed what a difference 10 feet or 1lb can make in a craft's ability to maintain stable flight.
Or are you trying to say a 10kg drone won't do the same damage as a 10kg model plane? I mean, it's either that or a 2.5kg drone will do less damage than a 2.5kg duck; and I'm pretty sure both hypothesis are wrong.
Or do you think all drones weigh under 1lb like the shit they sell at Brookstone or your local drug store? Buddy, there are some absolutely massive hobbyist drones out there. This one is almost 23kg, and it took me 30 seconds to find it on Google. Something like that could fly at or above 400ft with ease and pose a very real threat to manned aircraft; something like this, not so much on either front.
By increasing 360 minutes (6 hours) per day of sleep by 10% (to 396 minutes), you increase your life by 4%. Your day life includes the full day, all 1440 minutes (24 hours) of it, which you increase by 4%, to 1497.6 minutes. Sleeping an extra 36 minutes, then, grants you another 57.6 minutes of living, or another 21.6 minutes of waking time.
That's 151.2 minutes (a little over 2.5 hours) per week, 655.2 minutes (just shy of 11 hours) per month on average, and 7862.4 minutes (just over 131 hours, or just under 5.5 days) per year.
Depending on the size of the grain of salt with which you take this study, that is.
You know, I should probably just assume you stopped reading the article at your quote so you could come here and tell us all what it "actually" says, in which case you won't realize that is also actually says:
World-wide, there have been five known collisions. Three of these resulted in no damage beyond
scratches. However, one collision with a sport bi-plane in the United States of America (USA) in
2010 resulted in a crushed wing. Fortunately, the aircraft landed safely. Less fortunately, a Grob G
109B motor glider had a wing broken by an RPAS collision in 1997 in Germany, resulting in fatal
injury to the two people on board.
Maybe you should have read more than the first 2 paragraphs of the findings?
Literally the last two words of what you quoted. I was pointing it out because it entirely invalidates whatever point you might have been trying to make as we are discussing an event which occurred in New York which, last I checked, hasn't been invaded and taken over by the Aussies just yet. In fact, I'm fairly certain there is little danger of that happening.
Viewport, canvas, same thing. Yes, the browser's display space is always smaller than the screen resolution, on everything.
I suggest you look at the link I posted so you can understand just what I am referring to. The canvas on an iPad Pro is way larger than the 1366x1024 viewport it provides; closer to double that, as a matter of fact. Obviously, the canvas will be the screen size minus any toolbars, window borders, and other decorations or controls; the viewport on a desktop is often identical to the canvas, while this is almost never the case on mobile.
This is what I do for a living, I'm damn good at it, but even still I have provided references and am not expecting you to simply take my word. At the very least, check the references before you discount what I'm saying, you might just learn something.
I have not run across the Safari click events issue in iOS.
Depending on the control or element being tapped on, you may get both a click and a tap event, or just a tap event; the fact that you either get tap or both (and never just click) precludes simply aliasing tap and click for every interaction, as it would trigger the ones that get both twice. That mean you have to alias where you get only the tap, but make sure not to alias where you get both, unless you only care about mobile users, in which case you can ignore clicks altogether, but I've never had a client not care about the desktop. Likewise with mousedown, mouseup, mouseenter, and mouseexit, you can count on drag events, but you may also get mouse events in iOS, so you can't just blindly alias.
Regarding the underlying engines, I was under the impression they were all different for mobile, primarily because of what you're limited to in the mobile realm.
That hasn't been the case for some time now. On every browser I've used in recent memory, except Safari, the rendering engines are the same; or at least close enough that neither I nor my clients have spotted any difference that required a tweak for mobile. The javascript engines sometimes differ; the iOS Safari javascript engine necessarily differs because iOS registers touch events instead of clicks, while macOS Safari does not. On Android browsers, tap and click are synonymous and the only time I've noticed different behavior in recent memory is when the desktop version updates and the update hasn't been approved by Google yet (e.g. different versions of the engine).
If you're referring to the ability to be "pixel perfect" I truly feel your pain.
That's often a requirement on the major browsers and yes, it's absolutely possible (and even easy if you can convince the client to limit to current versions of FF, Chrome, and Safari, IE11, and Edge). If you can't, you get the client to agree to an hourly rate for any other browsers they want to specify, or you pass up the job. I've never had to pass up a job (though I've had to start getting up from the table once) and those hourly invoices sure make a nice bonus.
Regarding your personal challenges to using a mac mini, you can screen share with them and run them headless. For initial setup/configuration, just about any reasonably modern TV would have functioned as the monitor.
At any rate, in 2014 when I bought the MBP, my choices for a Mini were either a used 2012 or a hobbled current model. I wanted smoetihng I wouldn't have to replace for the froeseeable future and I'm guessing your Mini is from before "the hobbling". For my use case, this MBP will die long before it will have outlived its useful life; a used 2 year old 2012 Mini would have set me back about $600 and who knows what abuse it saw that may lead to an early failure, then the prospect of replacing it with who knows what because the new Minis are junk... I'd have ended up with the $2300 machine sooner or later anyway and a client was extending an advance against the first month's billables anyway.
You were talking about viewport being important from the standpoint of safari running within it, or did I misunderstand?
Viewport as in the piel dimensions at which the page is rendered. On mobile devices, that is almost never the actual display resolution. If you're not familiar with this conept, check out viewportsizes.com; you migh be surprised by what you find out about various devices. For example, I just learned that Firefox on this 1920x1200 Yoga Book provides a 1088x507 viewport, while Chrome provides 1098x524.
TBH, unless you're doing mobile / tablet development, I don't know why you'd need a specific set of devices.
Because Safari on iOS doesn't generate click events in some cases, so one must be able to test in order to know where a tap or drag event might be needed. Literally only iOS has this problem.
And because Safari rendering engines differ between iOS and macOS which, of course, necessitates having an iOS device for each viewport you wish to target with a responsive design, as each device has a fixed (by the OS) viewport. This is less of a problem on Android, where Chrome and Firefox use their own engines and typically match what the desktop version does. Another reason I prefer Android, to be quite honest.
1 year 8 months if you really want to nit-pick, but they didn't throw out everything they had; they were already building on a 2.6-series Linux kernel and using their in-house Java implementation (see your first reference) for codename "Sooner" before the iPhone was announced; they simply added touch screen support to that.
I have no idea what you're talking about there.
I had no idea what you were talking about, apparently; sorry for the confusion. I thought you were talking about an iPad Mini.
That said, no, it really wouldn't have done the trick for me at the time. I was working on a laptop, and only a laptop, at the time, and had no monitor to plug it in to. Yes, adding a monitor probably would have been cheaper, until you consider adding a desk to put the monitor on (I was short on desk space) and a bigger apartment to add the desk to. I've come a long way since then; that MacBook Pro is now mounted to the wall and acting as a remote framebuffer, which is how I would have set up a Mac Mini as well, but I'd have needed the aforementioned monitor in order to do so, at which point I'd have been buying a single-use monitor unless I also bought that desk and rented that bigger apartment.
So yes, a Mini would have worked, at considerably greater expense and effort than the MacBook Pro.
When I started talking about viewport sizes, it should perhaps have been a giveaway that I wasn't talking about the desktop; for that, you just resize the window.
After working for two years on Sooner, which was supposed to ship in late 2007... and whose launch was pushed back to fall 2008.
Seems like more than a few weeks to me, and that's assuming they didn't change course until the official iPhone announcement on January 9, 2007. They spent over a year reworking what they reworked. Well over a year, nearly two. Again, assuming they didn't start before the public announcement.
I guess a $400 mini wouldn't satisfy your Safari needs?
Not when I need to test against the larger viewport of the larger iPad Pro. No, it would not. Before that, I bought an Air because it was the newer device and would be supported longer (a new Mini model came out some time after that purchase). The Mini (and Ari) present a 1024x768 viewport, compared to the Pro's 1366x1024. That matters.
I also misspoke, the $600 iPad Air was the earlier purchase and the iPad Pro was not $600; I'm not sure why I typed Pro, because I knew that (I bought them both).
Oh, you're referring to the $2300 price tag. No, an iPad, regardless of model, would not serve my OS X Safari testing needs. And, as I said earlier, if I'm buying a Mac, I'm gonna buy one I can use as more than a damned browser (though it rarely sees that use today).
I also undervalued, because I don't recall exactly what I paid for each device. I can dig up receipts if you want to nit-pick.
I guess I don't get it. Generally the apps are fine for me, a widget is like Tom, in Office Space.
A widget is always there displaying your information or waiting for your interaction, while an app must be located, opened, and navigated through. Opening an app can take anywhere from almost no time, up to several seconds, depending on the app, and navigation can also be nontrivial. With a widget, I unlock, look, lock, done, 2 seconds. In well over 90% of cases, I won't have an app open in that same time, let alone have found the information I'm interested in.
Google basically did a "how fast can we rip off and write a clone of iOS with what we have" rush job, and they've been bandaiding it ever since.
Do you honestly believe that? Like, really? You think they put together a full operating system and hardware to run it on, build a handful of test units, got FCC approval, got it into manufacturing, and moved it onto store shelves in a matter of weeks? If they did, they should sell logistics as a service; just getting FCC approval for a device takes longer than people making that claim seem to think the entire R&D, testing, approval, manufacture, and shipping process took Google.
My Android phones range from $130 to $800, they're not exactly cheap.
What's the average, though, and did you have to buy them all at once? That was my point. With the exception of the $600 iPad Pro, the remaining $3900 outlay in Apple gear, just for web browsers, was all bought at once. You don't know pain, as it relates to testing gear, until you spend $2300 for a copy of Safari.
I can pick up a brand spanking new 64GB iPhone 8 for $649, and an SE for $129 (IIRC - otherwise $199 at Apple), so it really depends upon what you're shooting for there, but from my experiences you can grab either side of the mobile OS coin for similar money, with the exception of the Apple side all being on the latest OS version.
I never argued otherwise; but if you're buying a device for testing, you're going to buy the one that will be supported for the longest period of time, which means you're buying the newest device in most cases, so the $129 SE isn't really relevant here.
This is why I don't get the whole widgets thing. Usually the things I need to see are things I don't want joe random to be able to see merely by picking up my phone. Things I don't need to see don't need to be on the lock screen, qed.
And this is why Android's home screen (e.g. where your icons are, not visible while locked) widgets are better.
That is truly an understatement.
I don't think Slashdot will let me fit enough text into the 50 posts I get each day to properly elaborate.
Then again, basing CoreData on SQLite says all you need to know about that, except SQLite itself is actually far better and more reliable than CoreData.
A lot of Apple's architectural decisions leave me scratching my head. Then again, so do a lot of Google's... and Microsoft's... and don't get me started on Linux; if more VPS providers supported BSD, that's what I'd run my servers on.
At least you can get your hands on the Android devices you need for (relatively) cheap, though. Any mobile development I've done has been for specific devices, so I haven't had the same pain, but having to buy a Mac, a PC, and iPhone, an iPad, a new iPad because the viewport size changed, and an Android phone... just to test a few websites in a few browsers... well... That's $1400 in iPads alone, $2300 for the Mac because if I'm buying a Mac it's gonna be used as more than just an occasional web browser, I'm counting the iPhone because it meant my wife couldn't trade it in (the business bought it from her), so there's another $800, that's $4500 just in Apple gear to look at websites once in a blue moon. I'd be surprised to learn that you spent that on 20 non-flagship Android devices, to be honest. And yes, those are separate from my personal devices, they belong to my business. The PC and Android phone were bought for day to day use and would have been bought regardless of the need for a web browser, so I'm not counting what was paid for those; in any case, were I simply buying them for their browsers, I could have gotten away with spending less than $300.
Slashdot Mirror
Someone doesn't understand encryption very well...
it probably didn't feed into the computer directly but that was pretty much it.
Oh, but it probably did. The Altair 8800 wasn't the only computer to use that interface; it was simply the most well known.
Programming the Altair was an extremely tedious process. The user toggled the switches to positions corresponding to the desired 8080 microprocessor instruction or opcode in binary, then used the 'DEPOSIT NEXT' switch to load that instruction into the next address of the machine's memory. They repeated this step until all the opcodes of a presumably complete and correct program were in place.
did anyone ever do anything substantial in bit strings?
If you don't think inputting the code that allowed keyboard input (and printing or monitor display) of those hex values is substantial, then no. There was a time when computer interfaces were simply a series of switches; set your byte, then literally push it (with a button) to the stack. Everything we have today was built from that so, yes, I'd say that's substantial.
No, I can't. And neither can Apple.
What I can do, hiwever, is power dual 5k displays with Thunderbolt 3, which happens to share a port with USB-C. Incidentally, that's what Apple does, as well; the difference being that I can do it with a higher-end GPU than Apple is willing to sell me, thereby putting less stress on my GPU and ensuring it lasts longer. Heat is a component killer.
Supposedly, the data doesn't leave the phone; COPPA should not apply. That they spefically chose the age limit for COPPA tells me they believe it does apply and, since Apple's lawyers aren't likely to be idiots, that tells me the data probsbly leaves the phone.
Push is a synchronization method, as is pull. In fact, they're kind of the only two... you're either pulling data when you want it or having it pushed to you periodically or as it changes. There are a great many variations on that and they're sometimes combined (as in my example, above), but they're the only two methods. You are either requesting data (pull) or having it handed to you (push), how else would it get there?
If push is implemented properly, you register with the service and get fresh data at that time; then you get updates every time the data changes. Your data is never out of date (as long as you remain connected) with proper push. And if you lose connection at some point, well, a refresh button wouldn't work either.
The most common issue with pushing data is that developers will forget that they need to track their connectivity and re-register if connectivity has been lost for any period of time. That, of course, is not properly implemented.
Helo flies lower than is advisable hits a drone flying higher than is advisable then lands safely. Drone is obliterated. Clearly the drone is at fault?
No, but the operator of the drone is.
Injury or death does not absolve one of fault. If you step in front of a speeding car and get hurt or killed, you're still at fault for having stepped in front of the car.
Of course, the driver of the car is also at fault, as they were speeding. But, someone else being in the wrong too does not absolve you of responsbility; it's called shared responsibility. If the helo pilot was flying where he shouldn't have been, he is at fault; if the drone pilot was flying where he shouldn't have been, he is also at fault. If either of them had not fucked up, the incident would have been avoided. It took both of them fucking up in order for the incident to occur, therefore, they are both at fault.
I've really fucking had it with this "the thing I did wrong is okay because they did something wrong, too" mentality that seems to be running rampant lately. Seriously, it doesn't even make sense because the other person could just turn around and say the same thing; what they did wrong was okay because you did something wong. Okay, fine, neither of you take responsibility for whatever happened, and just both deal with the your own consequences of the resulting events separately. Don't want to do that? Both own up to your responsibility for the incident and deal with each others' consequences instead; after all it was your fuck up that caused those consequences for the other person -- even if their fuck up caused consequences for you.
It happens all too often. Bikes riding on the road are a perfect example. If a cyclist is obeying traffic laws and gets hit, it's the driver's fault; but, many cyclists think they're somehow absolved of the responsibility to obey the law. as a result, most accidents involving cyclists are, in the best case for the cyclist, shared responsibility. There was one guy who I swear was trying to get me to hit him every morning on my way to work. I didn't matter how early or how late I left, there he was, and he'd come from 100ft back or so as soon as he saw me and blow through his stop sign as I (who had no stop sign) began my right turn, turning left in front of me. Had I, one day, not stopped in time to avoid him (and there were a few close calls), it would have been not just because I fucked up, but also because he failed to stop as required by law; had either of us not fucked up, there would have been no accident. He consistently (seemingly purposely) fucked up and he's just lucky that I never did. The consequences for him would have been much worse than for me. One day, there was a bike pedal on the ground at that intersection and I never saw him again -- he must have tried that shit with a less skilled driver. Oops.
And that brings us back to personal responsibility. That cyclist was responsible for his own safety and obeying the law was just the first part of that. Awareness and avoidance are other parts (and there are a few more that are activity-specific) at which he clearly failed. When the potential consequences of someone fucking up (not necessarily you) are worse for you than they are for the other person, you have a personal responsibility -- for your own safety -- to observe and avoid, even if they're the one who's wrong. Take the cyclist; I wasn't there when he (presumably) got hit, maybe he did stop at the sign, maybe whoever 9presumably) hit himwaved him on, then gunned it and mowed him down. In that case, the driver is at fault for setting the incident up; but the cyclist failed to observe the driver, who was a known danger to the cyclist, and avoid the incident. As a result, the cyclist (presumably) was severely injured or killed.
Just as the drone was destroyed by the
Of course they do; they actually believed things would be better under Trump. A handful of us realized we were screwed either way; yes, we're also butthurt, but for different reasons.
it only takes one hole in the fence
That's why we need a wall, and we need the hackers to pay for it!
Sorry, couldn't resist. Carry on.
And so it didn't dawn on you that maybe bringing up that you game on a device other than your iPhone wouldn't be relevant?
Injuries from clamshell packaging are the result of idiots opening said packaging in idiotic ways and results only in injury to themselves. An collision between two aircraft is the result of idiots flying where they shouldn't and results in injury to others.
Please, don't be the inconsiderate prick that can't see how one idiot injuring someone else is worse than thousands of idiots injuring themselves. You can prevent self-injury by not being an idiot, but that doesn't save you from idiots (and you can't make someone else not be an idiot). If this were a story about idiots crashing their drones into their own heads, nobody would be calling them out for airspace violations; instead, we'd be calling them idiots, because that's what they are.
Mind you, everyone screaming that we need more regulation of airspace is an idiot, as well. Airspace is plenty-well regulated, but we do need better enforcement of those regulations. When people stop getting away with violations, we'll see fewer of them.
No, my point is that the poster posted a bunch of innuendo and tried to make it look like we had a credible report of a drone causing a fatality from Australia when what we actually had was a not so near miss, a bat strike, and Australia reporting that Germany reported that a very large conventional RC airplane once caused a motor glider fatality back in 1999.
Actually, the claim was never made that it happened in Australia. Furthermore, where it happened doesn't really much matter; a 10kg object would have taken down that manned aircraft anywhere in the world. In fact, as that glider was open-cockpit, a drone weighing a few ounces could have potentially brought it down by knocking the pilot unconscious.
Keep in mind that we're not discussing planes vs drones; we're discussing manned aircraft vs unmanned aircraft.
Also, guys, over here! I've spotted the irresponsible douchenugget who's giving all model aircraft operators a bad name!
Which of the 5 mentioned in the report was that? And do you really think a 2.25kg drone will do any less damage when 2.25kg ducks, which are much softer, have been known to take down planes?
Was your point really "well, it hasn't happened in Austrailia, so it must not be a big deal"? And 5lb is still quite small for a drone capable of stable flight at altitudes over 100 feet or so; 20lb (that is, ~10kg) drones fare much better than their lighter "toy" counterparts at higher altitudes where there are likely to be stronger winds. You'd me amazed what a difference 10 feet or 1lb can make in a craft's ability to maintain stable flight.
Or are you trying to say a 10kg drone won't do the same damage as a 10kg model plane? I mean, it's either that or a 2.5kg drone will do less damage than a 2.5kg duck; and I'm pretty sure both hypothesis are wrong.
Or do you think all drones weigh under 1lb like the shit they sell at Brookstone or your local drug store? Buddy, there are some absolutely massive hobbyist drones out there. This one is almost 23kg, and it took me 30 seconds to find it on Google. Something like that could fly at or above 400ft with ease and pose a very real threat to manned aircraft; something like this, not so much on either front.
By increasing 360 minutes (6 hours) per day of sleep by 10% (to 396 minutes), you increase your life by 4%. Your day life includes the full day, all 1440 minutes (24 hours) of it, which you increase by 4%, to 1497.6 minutes. Sleeping an extra 36 minutes, then, grants you another 57.6 minutes of living, or another 21.6 minutes of waking time.
That's 151.2 minutes (a little over 2.5 hours) per week, 655.2 minutes (just shy of 11 hours) per month on average, and 7862.4 minutes (just over 131 hours, or just under 5.5 days) per year.
Depending on the size of the grain of salt with which you take this study, that is.
World-wide, there have been five known collisions. Three of these resulted in no damage beyond scratches. However, one collision with a sport bi-plane in the United States of America (USA) in 2010 resulted in a crushed wing. Fortunately, the aircraft landed safely. Less fortunately, a Grob G 109B motor glider had a wing broken by an RPAS collision in 1997 in Germany, resulting in fatal injury to the two people on board.
Maybe you should have read more than the first 2 paragraphs of the findings?
Literally the last two words of what you quoted. I was pointing it out because it entirely invalidates whatever point you might have been trying to make as we are discussing an event which occurred in New York which, last I checked, hasn't been invaded and taken over by the Aussies just yet. In fact, I'm fairly certain there is little danger of that happening.
"in Austrailia."
Viewport, canvas, same thing. Yes, the browser's display space is always smaller than the screen resolution, on everything.
I suggest you look at the link I posted so you can understand just what I am referring to. The canvas on an iPad Pro is way larger than the 1366x1024 viewport it provides; closer to double that, as a matter of fact. Obviously, the canvas will be the screen size minus any toolbars, window borders, and other decorations or controls; the viewport on a desktop is often identical to the canvas, while this is almost never the case on mobile.
This is what I do for a living, I'm damn good at it, but even still I have provided references and am not expecting you to simply take my word. At the very least, check the references before you discount what I'm saying, you might just learn something.
I have not run across the Safari click events issue in iOS.
Depending on the control or element being tapped on, you may get both a click and a tap event, or just a tap event; the fact that you either get tap or both (and never just click) precludes simply aliasing tap and click for every interaction, as it would trigger the ones that get both twice. That mean you have to alias where you get only the tap, but make sure not to alias where you get both, unless you only care about mobile users, in which case you can ignore clicks altogether, but I've never had a client not care about the desktop. Likewise with mousedown, mouseup, mouseenter, and mouseexit, you can count on drag events, but you may also get mouse events in iOS, so you can't just blindly alias.
Regarding the underlying engines, I was under the impression they were all different for mobile, primarily because of what you're limited to in the mobile realm.
That hasn't been the case for some time now. On every browser I've used in recent memory, except Safari, the rendering engines are the same; or at least close enough that neither I nor my clients have spotted any difference that required a tweak for mobile. The javascript engines sometimes differ; the iOS Safari javascript engine necessarily differs because iOS registers touch events instead of clicks, while macOS Safari does not. On Android browsers, tap and click are synonymous and the only time I've noticed different behavior in recent memory is when the desktop version updates and the update hasn't been approved by Google yet (e.g. different versions of the engine).
If you're referring to the ability to be "pixel perfect" I truly feel your pain.
That's often a requirement on the major browsers and yes, it's absolutely possible (and even easy if you can convince the client to limit to current versions of FF, Chrome, and Safari, IE11, and Edge). If you can't, you get the client to agree to an hourly rate for any other browsers they want to specify, or you pass up the job. I've never had to pass up a job (though I've had to start getting up from the table once) and those hourly invoices sure make a nice bonus.
Nothing erases pain like pay.
Regarding your personal challenges to using a mac mini, you can screen share with them and run them headless. For initial setup/configuration, just about any reasonably modern TV would have functioned as the monitor.
At any rate, in 2014 when I bought the MBP, my choices for a Mini were either a used 2012 or a hobbled current model. I wanted smoetihng I wouldn't have to replace for the froeseeable future and I'm guessing your Mini is from before "the hobbling". For my use case, this MBP will die long before it will have outlived its useful life; a used 2 year old 2012 Mini would have set me back about $600 and who knows what abuse it saw that may lead to an early failure, then the prospect of replacing it with who knows what because the new Minis are junk... I'd have ended up with the $2300 machine sooner or later anyway and a client was extending an advance against the first month's billables anyway.
You were talking about viewport being important from the standpoint of safari running within it, or did I misunderstand?
Viewport as in the piel dimensions at which the page is rendered. On mobile devices, that is almost never the actual display resolution. If you're not familiar with this conept, check out viewportsizes.com; you migh be surprised by what you find out about various devices. For example, I just learned that Firefox on this 1920x1200 Yoga Book provides a 1088x507 viewport, while Chrome provides 1098x524.
TBH, unless you're doing mobile / tablet development, I don't know why you'd need a specific set of devices.
Because Safari on iOS doesn't generate click events in some cases, so one must be able to test in order to know where a tap or drag event might be needed. Literally only iOS has this problem.
And because Safari rendering engines differ between iOS and macOS which, of course, necessitates having an iOS device for each viewport you wish to target with a responsive design, as each device has a fixed (by the OS) viewport. This is less of a problem on Android, where Chrome and Firefox use their own engines and typically match what the desktop version does. Another reason I prefer Android, to be quite honest.
Something like 1.5 years.
1 year 8 months if you really want to nit-pick, but they didn't throw out everything they had; they were already building on a 2.6-series Linux kernel and using their in-house Java implementation (see your first reference) for codename "Sooner" before the iPhone was announced; they simply added touch screen support to that.
I have no idea what you're talking about there.
I had no idea what you were talking about, apparently; sorry for the confusion. I thought you were talking about an iPad Mini.
That said, no, it really wouldn't have done the trick for me at the time. I was working on a laptop, and only a laptop, at the time, and had no monitor to plug it in to. Yes, adding a monitor probably would have been cheaper, until you consider adding a desk to put the monitor on (I was short on desk space) and a bigger apartment to add the desk to. I've come a long way since then; that MacBook Pro is now mounted to the wall and acting as a remote framebuffer, which is how I would have set up a Mac Mini as well, but I'd have needed the aforementioned monitor in order to do so, at which point I'd have been buying a single-use monitor unless I also bought that desk and rented that bigger apartment.
So yes, a Mini would have worked, at considerably greater expense and effort than the MacBook Pro.
When I started talking about viewport sizes, it should perhaps have been a giveaway that I wasn't talking about the desktop; for that, you just resize the window.
Actually, they did
Oh? From your last reference:
After working for two years on Sooner, which was supposed to ship in late 2007 ... and whose launch was pushed back to fall 2008.
Seems like more than a few weeks to me, and that's assuming they didn't change course until the official iPhone announcement on January 9, 2007. They spent over a year reworking what they reworked. Well over a year, nearly two. Again, assuming they didn't start before the public announcement.
I guess a $400 mini wouldn't satisfy your Safari needs?
Not when I need to test against the larger viewport of the larger iPad Pro. No, it would not. Before that, I bought an Air because it was the newer device and would be supported longer (a new Mini model came out some time after that purchase). The Mini (and Ari) present a 1024x768 viewport, compared to the Pro's 1366x1024. That matters.
I also misspoke, the $600 iPad Air was the earlier purchase and the iPad Pro was not $600; I'm not sure why I typed Pro, because I knew that (I bought them both).
Oh, you're referring to the $2300 price tag. No, an iPad, regardless of model, would not serve my OS X Safari testing needs. And, as I said earlier, if I'm buying a Mac, I'm gonna buy one I can use as more than a damned browser (though it rarely sees that use today).
I also undervalued, because I don't recall exactly what I paid for each device. I can dig up receipts if you want to nit-pick.
Fucking seriously?
No.
Because they're flying out of their country.
I guess I don't get it. Generally the apps are fine for me, a widget is like Tom, in Office Space.
A widget is always there displaying your information or waiting for your interaction, while an app must be located, opened, and navigated through. Opening an app can take anywhere from almost no time, up to several seconds, depending on the app, and navigation can also be nontrivial. With a widget, I unlock, look, lock, done, 2 seconds. In well over 90% of cases, I won't have an app open in that same time, let alone have found the information I'm interested in.
Google basically did a "how fast can we rip off and write a clone of iOS with what we have" rush job, and they've been bandaiding it ever since.
Do you honestly believe that? Like, really? You think they put together a full operating system and hardware to run it on, build a handful of test units, got FCC approval, got it into manufacturing, and moved it onto store shelves in a matter of weeks? If they did, they should sell logistics as a service; just getting FCC approval for a device takes longer than people making that claim seem to think the entire R&D, testing, approval, manufacture, and shipping process took Google.
My Android phones range from $130 to $800, they're not exactly cheap.
What's the average, though, and did you have to buy them all at once? That was my point. With the exception of the $600 iPad Pro, the remaining $3900 outlay in Apple gear, just for web browsers, was all bought at once. You don't know pain, as it relates to testing gear, until you spend $2300 for a copy of Safari.
I can pick up a brand spanking new 64GB iPhone 8 for $649, and an SE for $129 (IIRC - otherwise $199 at Apple), so it really depends upon what you're shooting for there, but from my experiences you can grab either side of the mobile OS coin for similar money, with the exception of the Apple side all being on the latest OS version.
I never argued otherwise; but if you're buying a device for testing, you're going to buy the one that will be supported for the longest period of time, which means you're buying the newest device in most cases, so the $129 SE isn't really relevant here.
This is why I don't get the whole widgets thing. Usually the things I need to see are things I don't want joe random to be able to see merely by picking up my phone. Things I don't need to see don't need to be on the lock screen, qed.
And this is why Android's home screen (e.g. where your icons are, not visible while locked) widgets are better.
That is truly an understatement.
I don't think Slashdot will let me fit enough text into the 50 posts I get each day to properly elaborate.
Then again, basing CoreData on SQLite says all you need to know about that, except SQLite itself is actually far better and more reliable than CoreData.
A lot of Apple's architectural decisions leave me scratching my head. Then again, so do a lot of Google's... and Microsoft's... and don't get me started on Linux; if more VPS providers supported BSD, that's what I'd run my servers on.
At least you can get your hands on the Android devices you need for (relatively) cheap, though. Any mobile development I've done has been for specific devices, so I haven't had the same pain, but having to buy a Mac, a PC, and iPhone, an iPad, a new iPad because the viewport size changed, and an Android phone... just to test a few websites in a few browsers... well... That's $1400 in iPads alone, $2300 for the Mac because if I'm buying a Mac it's gonna be used as more than just an occasional web browser, I'm counting the iPhone because it meant my wife couldn't trade it in (the business bought it from her), so there's another $800, that's $4500 just in Apple gear to look at websites once in a blue moon. I'd be surprised to learn that you spent that on 20 non-flagship Android devices, to be honest. And yes, those are separate from my personal devices, they belong to my business. The PC and Android phone were bought for day to day use and would have been bought regardless of the need for a web browser, so I'm not counting what was paid for those; in any case, were I simply buying them for their browsers, I could have gotten away with spending less than $300.