More memory is usually just a matter of switching out a chip for a different chip of the same form factor. To double the battery life, you have to double the battery's volume. Inside a tablet there isn't a cubic millimeter that isn't accounted for, which means that the only way to put in a bigger battery is to build a different case, which has a cascading effect throughout the entire parts list. Much harder.
Plus, if you double the battery, some people are bound to complain about the longer charging time, which means they'll have to design around that, too.
One thing nobody's mentioned yet is that big commercial applications can have hundreds of separately ordered bits and pieces. That often affects the installation process, and can add a lot of complexity. The more paranoid vendors won't just have you install the whole thing and then disable what you haven't paid for, for fear you might crack the rest. Sometimes it's not even technically feasible either, given the app's internal dependencies.
We've all dealt with vendors and their licensing departments. Even if the technical side of it works perfectly, if there are enough different things to be licensed, sooner or later someone's bound to give you the wrong magic number.
If I had to solve this, I'd buy a modern box and set up a virtual machine on it that runs XP. The virtual hardware will last a lot longer than the physical hardware it emulates.
Oh, and I'd do this long before the last XP machine breaks, so that I'd have plenty of time to port and test legacy apps.
I'm not sure if they were in the 3D Pavilion or in one of the other tents, but I didn't see them--I'd definitely have remembered! If their Kickstarter page is to be believed (and I have no reason to think otherwise), the $2700 theirs will cost buys you a lot better rendering and a lot less shape restriction than any of the "conventional" 3D printers out there. Personally, I'll take a serious look at them after they've been in production for a year. I'm less concerned with the printer itself than whether you're tied forever to their proprietary resin, whether they can make it in other colors (ideally, mixable over a wide gamut), and how well they can produce it in quantity. I'd also like to see a two-color version of it eventually.
I have to admit: I find it exciting just watching this market develop. Reminds me of the late 70's when these newfangled computer thingies came out and nobody was quite sure what they'd be best at.
Since all I looked at were completed objects, I can't say anything about how fast they were produced, how reliable or easy to calibrate the printers are, etc. What I mostly looked for were irregularities. In a 3D printed object, the layers are very visible. If you think of a cylinder, you expect the sides to be as smooth as possible, i.e., no protrusions or indentations. The layers should be completely horizontal, no glitches or waviness that make you think the printhead jiggled or anything. If you think of a sphere, the topmost layers should look like perfect concentric circles, and the top shouldn't look like it's about to cave in.
It was insanely crowded in the 3D Printer Pavilion, so once I decided that a vendor's objects were not the best, I moved on. But there were two noteworthy units: Sorry to say, the new Makerbot 2 was a disappointment, given that it's one of the most expensive units at $2800. The objects they had on display were some of the worst. The surprise winner, and the one I'm recommending to a nonprofit children's museum I'm working with that wants to buy one, was the Tinkerines Ditto. It produced the best objects, and at $900 in kit form or $1400 assembled, it was amazing bang for the buck.
Tinkerines is new to the scene, so they don't yet have a dual-nozzle head, nor do they yet support ABS plastic (the necessary heated base is still being developed), only PLA. But for our application, it's perfect. The people were really nice too, despite the crowds and the cacophony in the tent.
(Disclaimer: I have no connection with any vendor except as a customer or with Maker Faire except as an attendee.)
...Maker Faire was a goldmine. Every major vendor was there, and they all had samples of the classic objects everybody uses for demos, so it was very easy to compare the quality of the output. (That is, presuming that the ones that stood out didn't just print 500 identical objects and bring the one good one.)
Movie theaters in the 60, 70's and even 80's were a social experience, people dressed up in suits and ties, women in fancy dresses to go out to the movies
Really? Not in the 60's 70's and 80's that I lived in. What was different was that people were better behaved. But the only time you dressed up was to impress your date.
And WTF makes you think we had the luxury of walking out of college thinking we had all the knowledge we'd ever need? Things changed as fast then as they do now. New technologies emerged just as often, and we had to keep up with them just like everyone has to today. You have to fight tooth and nail for your job? Oh, cry me a river. I was dodging downsizing and offshoring while you were still swimming around in your father's balls. You know how I did it? The same way you do, by keeping up with technology and being able to provide what my employers need.
But there's more to it than chasing after this week's hot new acronym. At some point you won't be able to make it as a code monkey or even a designer. That's all going to be done by drones who work for fifty cents an hour an no bathroom breaks. If you want to stay technical throughout your career and not take the easy PHB route, you're going to have to pick something your employers will NEVER be able to live without, and be the best at it on the planet. Hint: That job title won't be "web designer" or "data modeler" or, God forbid, "Agilist".
In my case, I design and build development labs, both hardware and software. I start with an empty room, and put together the infrastructure you use to do your job, whatever that is. I may not have to know every last detail of every new technology that comes out, but I have to be able to build you a lab that takes full advantage of whatever technology you say you need. And I have to keep that lab secure, and make sure nothing in it crashes. As long as there's software development, there's going to be a need for what I do.
Can you say the same thing about what you're doing right now?
No, I don't. Not getting religion on Agile, and not liking the word "scrum" are two different things. It's like whether you think structured programming is a good thing versus liking the Pascal programming language.
You might want to stop assuming that everyone you disagree with is some naive kid right (or not yet) out of college. Some of us have seen these fads come and go time and again. Every one of them claims to be the new One True Way to make software suck less. Each contributes a bit, but not nearly as much as its true believers think.
No, I understand Agile perfectly well, TYVM. But like all the Next Big Things we've seen over the decades, too many people think it's a one-size-fits-all panacea, and force it on all projects everywhere and forevermore, instead of smartly taking advantage of the parts of it that work for the actual task at hand.
Like any methodology, imagine it being applied to the software running in your grandmother's heart monitor, or the flight software in your son's fighter jet, or any other application where if the software crashes, people you care about will die. No methodology popularized in the last 40 years can pass that test without some sort of modification and customization, including disregarding one or more of its basic principles.
And regardless of the merits of the methodology itself, I still maintain that "scrum" is a stupid word choice. At least Kanban ("signboard") evokes an image of communication.
I've always maintained that programming should be thought of more as a trade then a profession. We were all apprentices at one time or another.
(I also haven't gotten religion on Agile. Who's the genius that thought a word representing a bunch of sweaty grunting guys pushing against each other in the mud, expending tons of energy and going nowhere was supposed to make me think of increased nimbleness and productivity?)
When I walked in (at age 41 and 20 years in the business, BTW), there was no sysadmin, and the development lab consisted of two PCs and supported 15 users. I was the only sysadmin and for almost eight years I was on call 24x365. At the end, the lab had about 150 tracked assets supporting 250 local and remote users. The above story was early on in that time period, and disk space wasn't even close to the top of my worries. Even after the environment matured and stabilized, of the seven development sites on the project, what I did at my site was done by three full-time people at each of the others, yet 40-45-hour weeks were my norm. For all but two of those years, I had four-nines uptime, and the years I didn't were due to power outages longer than my UPS could handle. (To get to five-nines would not have been cost-effective for what we did.) Nobody ever lost any data for any reason. Not even once.
You bet your arrogant, condescending kids-these-days ass I analyzed and planned (and budgeted, and audited, and standardized, and measured). If you want to think that I spent all that time putting out fires and slapping band-aids on everything, go right ahead. My bosses, my users, and my successor knew different.
Measuring how often something *doesn't* crash is extremely hard to show to the bean-counters. So, be ready to demo.
True story: When I started a sysadmin job, we had JBODs that routinely ran out of space, causing all sorts of downtime problems, like leaving the whole building dead in the water for days. I convinced TPTB that we needed decent storage (in this case, NetApp), but many of them choked when they saw both the purchase and maintenance costs. After we had it installed, I saw that a volume was close to hitting the wall. Before doing anything, I called in the most skeptical of the PHBs, and said, "Wanna see the NetApp pay for itself?"
I showed him the alarm that indicated a space problem, and told him we were on the verge of going down for two days. I waited for his skin to turn pale, and at the right moment, I said, "But we won't, because the NetApp can do this," and in a few keystrokes and mouse clicks, I added enough space to the volume.
I then told him that things like this happen once or twice a week, and I fix them without anyone knowing anything went wrong, but that I documented them in the trouble ticketing system I had installed, so if anyone wanted to know how many disasters were prevented by having decent storage, that's where they should look.
That didn't completely solve the problem of the thousand successes going unnoticed and the one failure never forgotten, but it came close.
If the compression forms a (near) solid column from the point of impact to the bottom of the container, that implies that as armor it would do exactly what you don't want it to do, which is transmit the impact through to the wearer over a relatively small area. Effective armor spreads the impact over a wide area, or better yet, turns it into a shock wave that spreads and dissipates throughout the armor.
Slashdot Mirror
More memory is usually just a matter of switching out a chip for a different chip of the same form factor. To double the battery life, you have to double the battery's volume. Inside a tablet there isn't a cubic millimeter that isn't accounted for, which means that the only way to put in a bigger battery is to build a different case, which has a cascading effect throughout the entire parts list. Much harder.
Plus, if you double the battery, some people are bound to complain about the longer charging time, which means they'll have to design around that, too.
One thing nobody's mentioned yet is that big commercial applications can have hundreds of separately ordered bits and pieces. That often affects the installation process, and can add a lot of complexity. The more paranoid vendors won't just have you install the whole thing and then disable what you haven't paid for, for fear you might crack the rest. Sometimes it's not even technically feasible either, given the app's internal dependencies.
We've all dealt with vendors and their licensing departments. Even if the technical side of it works perfectly, if there are enough different things to be licensed, sooner or later someone's bound to give you the wrong magic number.
Reminds me of the charge once brought against Howard Zinn: "failure to quit".
If I had to solve this, I'd buy a modern box and set up a virtual machine on it that runs XP. The virtual hardware will last a lot longer than the physical hardware it emulates.
Oh, and I'd do this long before the last XP machine breaks, so that I'd have plenty of time to port and test legacy apps.
It's not a Sprint thing; they just happen to be the first carrier offering it to consumers. Check out www.startstar.co.
I'm not sure if they were in the 3D Pavilion or in one of the other tents, but I didn't see them--I'd definitely have remembered! If their Kickstarter page is to be believed (and I have no reason to think otherwise), the $2700 theirs will cost buys you a lot better rendering and a lot less shape restriction than any of the "conventional" 3D printers out there. Personally, I'll take a serious look at them after they've been in production for a year. I'm less concerned with the printer itself than whether you're tied forever to their proprietary resin, whether they can make it in other colors (ideally, mixable over a wide gamut), and how well they can produce it in quantity. I'd also like to see a two-color version of it eventually.
I have to admit: I find it exciting just watching this market develop. Reminds me of the late 70's when these newfangled computer thingies came out and nobody was quite sure what they'd be best at.
Since all I looked at were completed objects, I can't say anything about how fast they were produced, how reliable or easy to calibrate the printers are, etc. What I mostly looked for were irregularities. In a 3D printed object, the layers are very visible. If you think of a cylinder, you expect the sides to be as smooth as possible, i.e., no protrusions or indentations. The layers should be completely horizontal, no glitches or waviness that make you think the printhead jiggled or anything. If you think of a sphere, the topmost layers should look like perfect concentric circles, and the top shouldn't look like it's about to cave in.
It was insanely crowded in the 3D Printer Pavilion, so once I decided that a vendor's objects were not the best, I moved on. But there were two noteworthy units: Sorry to say, the new Makerbot 2 was a disappointment, given that it's one of the most expensive units at $2800. The objects they had on display were some of the worst. The surprise winner, and the one I'm recommending to a nonprofit children's museum I'm working with that wants to buy one, was the Tinkerines Ditto. It produced the best objects, and at $900 in kit form or $1400 assembled, it was amazing bang for the buck.
Tinkerines is new to the scene, so they don't yet have a dual-nozzle head, nor do they yet support ABS plastic (the necessary heated base is still being developed), only PLA. But for our application, it's perfect. The people were really nice too, despite the crowds and the cacophony in the tent.
(Disclaimer: I have no connection with any vendor except as a customer or with Maker Faire except as an attendee.)
...Maker Faire was a goldmine. Every major vendor was there, and they all had samples of the classic objects everybody uses for demos, so it was very easy to compare the quality of the output. (That is, presuming that the ones that stood out didn't just print 500 identical objects and bring the one good one.)
I was trying to figure out when I got here. I want to say late 1990s but it might not have been until 2000 or 2001.
EmacsM-^H Firefox would be a great OS if only it had a decent text editorM-^HM-^H web browser.
We smile all the time, just not when you're around.
Movie theaters in the 60, 70's and even 80's were a social experience, people dressed up in suits and ties, women in fancy dresses to go out to the movies
Really? Not in the 60's 70's and 80's that I lived in. What was different was that people were better behaved. But the only time you dressed up was to impress your date.
No, that's "scrum".
Agile != Scrum.
But thanks for the condescension. It's what I live for.
I know Agile and Scrum are not the same things.
And WTF makes you think we had the luxury of walking out of college thinking we had all the knowledge we'd ever need? Things changed as fast then as they do now. New technologies emerged just as often, and we had to keep up with them just like everyone has to today. You have to fight tooth and nail for your job? Oh, cry me a river. I was dodging downsizing and offshoring while you were still swimming around in your father's balls. You know how I did it? The same way you do, by keeping up with technology and being able to provide what my employers need.
But there's more to it than chasing after this week's hot new acronym. At some point you won't be able to make it as a code monkey or even a designer. That's all going to be done by drones who work for fifty cents an hour an no bathroom breaks. If you want to stay technical throughout your career and not take the easy PHB route, you're going to have to pick something your employers will NEVER be able to live without, and be the best at it on the planet. Hint: That job title won't be "web designer" or "data modeler" or, God forbid, "Agilist".
In my case, I design and build development labs, both hardware and software. I start with an empty room, and put together the infrastructure you use to do your job, whatever that is. I may not have to know every last detail of every new technology that comes out, but I have to be able to build you a lab that takes full advantage of whatever technology you say you need. And I have to keep that lab secure, and make sure nothing in it crashes. As long as there's software development, there's going to be a need for what I do.
Can you say the same thing about what you're doing right now?
No, I don't. Not getting religion on Agile, and not liking the word "scrum" are two different things. It's like whether you think structured programming is a good thing versus liking the Pascal programming language.
You might want to stop assuming that everyone you disagree with is some naive kid right (or not yet) out of college. Some of us have seen these fads come and go time and again. Every one of them claims to be the new One True Way to make software suck less. Each contributes a bit, but not nearly as much as its true believers think.
No, I understand Agile perfectly well, TYVM. But like all the Next Big Things we've seen over the decades, too many people think it's a one-size-fits-all panacea, and force it on all projects everywhere and forevermore, instead of smartly taking advantage of the parts of it that work for the actual task at hand.
Like any methodology, imagine it being applied to the software running in your grandmother's heart monitor, or the flight software in your son's fighter jet, or any other application where if the software crashes, people you care about will die. No methodology popularized in the last 40 years can pass that test without some sort of modification and customization, including disregarding one or more of its basic principles.
And regardless of the merits of the methodology itself, I still maintain that "scrum" is a stupid word choice. At least Kanban ("signboard") evokes an image of communication.
I've always maintained that programming should be thought of more as a trade then a profession. We were all apprentices at one time or another.
(I also haven't gotten religion on Agile. Who's the genius that thought a word representing a bunch of sweaty grunting guys pushing against each other in the mud, expending tons of energy and going nowhere was supposed to make me think of increased nimbleness and productivity?)
Short form: If you admit it, you're addicted. If you don't, you're in denial.
Allie, put that on a T-shirt and I'll buy it!
When I walked in (at age 41 and 20 years in the business, BTW), there was no sysadmin, and the development lab consisted of two PCs and supported 15 users. I was the only sysadmin and for almost eight years I was on call 24x365. At the end, the lab had about 150 tracked assets supporting 250 local and remote users. The above story was early on in that time period, and disk space wasn't even close to the top of my worries. Even after the environment matured and stabilized, of the seven development sites on the project, what I did at my site was done by three full-time people at each of the others, yet 40-45-hour weeks were my norm. For all but two of those years, I had four-nines uptime, and the years I didn't were due to power outages longer than my UPS could handle. (To get to five-nines would not have been cost-effective for what we did.) Nobody ever lost any data for any reason. Not even once.
You bet your arrogant, condescending kids-these-days ass I analyzed and planned (and budgeted, and audited, and standardized, and measured). If you want to think that I spent all that time putting out fires and slapping band-aids on everything, go right ahead. My bosses, my users, and my successor knew different.
Measuring how often something *doesn't* crash is extremely hard to show to the bean-counters. So, be ready to demo.
True story: When I started a sysadmin job, we had JBODs that routinely ran out of space, causing all sorts of downtime problems, like leaving the whole building dead in the water for days. I convinced TPTB that we needed decent storage (in this case, NetApp), but many of them choked when they saw both the purchase and maintenance costs. After we had it installed, I saw that a volume was close to hitting the wall. Before doing anything, I called in the most skeptical of the PHBs, and said, "Wanna see the NetApp pay for itself?"
I showed him the alarm that indicated a space problem, and told him we were on the verge of going down for two days. I waited for his skin to turn pale, and at the right moment, I said, "But we won't, because the NetApp can do this," and in a few keystrokes and mouse clicks, I added enough space to the volume.
I then told him that things like this happen once or twice a week, and I fix them without anyone knowing anything went wrong, but that I documented them in the trouble ticketing system I had installed, so if anyone wanted to know how many disasters were prevented by having decent storage, that's where they should look.
That didn't completely solve the problem of the thousand successes going unnoticed and the one failure never forgotten, but it came close.
If the compression forms a (near) solid column from the point of impact to the bottom of the container, that implies that as armor it would do exactly what you don't want it to do, which is transmit the impact through to the wearer over a relatively small area. Effective armor spreads the impact over a wide area, or better yet, turns it into a shock wave that spreads and dissipates throughout the armor.
I work remotely almost all the time, and I routinely access remote systems in all the normal ways (VNC, remote X, RDS, etc.)
> Starting the VNC server, with all the right arguments, on the remote end
$ vncserver -geometry WxH
> Making sure applications on the remote end will display on the VNC server (e.g. setting your DISPLAY variable)
VNC servers are pretty good about starting GNOME (or whatever) sessions; $DISPLAY is set correctly by default.
> Starting the VNC client on the local end, with all the right arguments
> Determining what port number to use
All you need is the right server/port number, which you're given when you start the VNC server.
> Securing the VNC server against unauthorized access if there are other users on either the remote or the local end
You can set a password for your VNC session that's different from your Unix (or whatever) password.
IOW, this is no harder than RDS, and over WANs/VPNs, you tend to get much better performance than pointing $DISPLAY back to your local machine.
I like that. Who needs bombs when you can effectively DDoS the airport?
...from my purchase of *exactly* one gallon of gas.