Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Smart! (Score 2) 183

And when they refused to take cash, you were no longer required to pay and could have, in fact, taken them to court over it.

IF you offer to pay any debt to any entity with cash, our current laws require them to take that cash or absolve you of the debt.

Not saying your anecdotal evidence is not true - just that there were larger ramifications to what occurred than perhaps you were aware.

This only applies to debts, but not to fees. For instance, to file up for a homestead exception, I needed to file up a note of residence, and that requires a $10 fee, to be paid with a check to the county clerk. Cash won't be accepted. Great, I'm in not obligation to pay, but if I don't then I don't get my homestead exception and shit, it's $3K more on real estate taxes.

The same thing with fines. Can we consider these debts owned to the state? Most fines can only be paid with a check or credit card. One could take it to court, but what sort of a Pyrrhic victory would that be?

Some fights are just not worth it.

A legal right to pay cash to private entities, though, that is something I would fight for.

Comment "killer app" != "app" (Score 1) 98

Didn't we call them "programs"?

And "killer app" was a concept long before smartphones.

Everyone in this industry will have differing experience. This is mine: "killer app" is something that came during the dot-com when everyone and their grandma wanted a spot in the .com valuation orgy.

But as far as I remember, the "app" in "killer app" never carried over to the general lingo. It was rarely "application", but "program". Sure, we used "applications" in formal docs and lingo, but in the typical work vernacular, either among ourselves or when interacting with users, it was typically "programs" (specially if these were in-house built ones.)

I squint my eyes trying to remember when we the word "apps" started replacing "programs". And I remember my years when companies started ditching their token ring networks in favor of Ethernet, offices weren't relying on Compuserve anymore to go to the internet and businesses started developing their own "intranets" (btw, it was a good move to pepper your CV with "intranet", headhunters used to like that shit, like catnip or something.)

And if my memory serves me well, we used to refer to those as "systems" initially as a connotation that these weren't "programs" that you install on a desktop, but multi-tiered systems.

YMMV obviously, but I think I didn't start seeing "application" as a general word till 2005-2006 when finally the whole industry was going full swing, scaling up from the ASP model of things into the SaaS model we see today.

That's my experience, and experience is always local (I'm in South Florida, a tech wasteland). Other, more technically diverse markets might have seen a different pattern in their professional lingo.

Comment Re:And how does this help the people? (Score 1) 67

Spinoff technology to fields other than space and space exploration?

Perhaps. Unlikely that anything needed for rendezvous with a comet would have commercial spin-offs, but there may be some materials improvements that trickle down.

Better understanding of the Solar System

Sure, that's a great thing - knowledge is good, and if this is purely in the pursuit of scientific knowledge, I'd be okay with that too.

leading to the human race getting a colony *somewhere off this rock* in preparation for the next Earth-bound major extinction event?

Now you're just being stupid. Is the human race going to live on comets when we get "off this rock"? Orbital mechanics are well understood at this point, so rendezvous with an object traveling through space isn't really advancing the knowledge of the human race.

Yes it does. It helps understand the mechanics and logistics of landing over a comet (such type of landings are not just ruled by orbital mechanics alone.) When we learn to reliably and predictably land over such objects, then we open for ourselves the opportunity to mining them. There is a shitload of ice and building materials on those floating monsters. Not only you open the opportunity to mining them, but to alter their trajectories, or even hollow them up and spinning them to get 1g.

Imagine you can take a 4km by 4km comet like 67P/Churyumov–Gerasimenko, alter its orbit and park it. Then carve it from the inside out, pilling out the dug out material, melting it. Filter it, separating it into portions of pure water and sludge then mixed with dust, or regolith, synth metal, ceramics or whatever that, when frozen becomes get a robust pykrete.

Rinse and repeat. Pure water = inner layers, pykrete = outer, protective layers. Rinse and repeat until you get an ice station with an embedded 4km by 4km cylindrical space in it, covered by several kms of ice.

Spin it till you get some decent g forces. Rinse and repeat, we have millions of floating icebergs on the solar system once we figure out how to use fusion. Fusion + a shitload of Hydrogen == no longer a need for depending on solar power to colonize beyond the belt.

Sounds impossible? Well fuck, we landed on the moon, we developed nuclear power and that just a mere century from the time of the steam engine. It was impossible to cross the seas, but people did it. Hell, even prehistoric man with nothing but hides, bows and arrows ventured into the Artic... and conquered.

Technologies advance, and if we really had the motivation, shit like what I just described could be done within decades. For what stop us is not so much technology, but economics and politics.

Barring a fundamental revolution in our understanding and knowledge of physics, there is no practical way we're ever going to cut the cord between Earth and even the remotest colonies in the solar system. As earth lives and dies, so die our colonies inside the solar system. And fundamentally, there's NO way we're sending a manned mission to another star unless:

What a load of cock. Colony survival does not depend on orbital mechanics or anything of the sort. It would depend on the state of technology. And there is nothing to prevent technology to advance to the point of making self-sustaining colonies.

Comment Re:Just a thought... (Score 1) 291

If they knew she was a woman, it was because she told them.

Github pull requests come with the username of the requestor. Anyone who (a) has a gender specific name and (b) uses their real name on hub will have a readily apparent gender. I also notice that you ascribe the gender differences because the woman must have told them their gender. No where do you you make the same accusation at men.

Massive double standards there.

My thoughts exactly. These people must have some type of contortionist genes in them because that's the only way they can reach so far up their asses to pull such arguments without busting a vertebrae.

Comment Re:In short (Score 1) 96

" I would love to see a multi-node thermostat that is affordable (and secure, if it is not, fuck that), adaptive, that learns to program itself, that I can control (securely) over wi-fi..."

I'm genuinely curious: why?

Fair enough. With it, it would open possibilities of reporting fluctuations over wi-fi which I can then see over one of my smart phones, tablet or laptop. Laziness/convenience kind of a thing.

"Adaptive" - adaptive to what? How many houses do you live in?

Fair enough also. This goes along the multi-node feature I was wanting. For a large enough house, I could have two separate A/C systems - one for the living areas, and another for the bedrooms. An initial investment would cost $$$ obviously, but it would save $$$ more over time if I can simply shut either one as needed. I've seen the effect in terms of cost savings in houses that have done just that.

"Learns to program itself" Why? Aren't you going to be there? Don't you ultimately at some point have to tell it "that's too hot, that's too cold"?

A single thermostat is still not good enough when your house experiences different temperature fluctuations. For example, due to my house's orientation, the master bedroom gets way too hot or way too cold before the thermostat detects it is too hot or too cold. Having more than one across the room that can coordinate with one another, the whole system adapts to the desired ranges by just programming the "master" node.

If you couple that with more than one A/C system, then it goes further by deciding which one to run and when. Moreover, most thermostats only operate with either refrigeration or heating. If you want cooling, you have to turn that on and turn heating off (and viceversa). Here in Florida, you can get some unpleasant fluctuations, specially if your house has a specific shape and orientation and if you are living next to a lake.

For example, yesterday it was 49F on my bedroom (not good for my little children), and then at noon (due to the direct sunlight), parts of the house quickly rose up to the upper 70's. In my ideal situation, I want that automated and handled it autonomously without me having to input my desired parameters only once.

It is a first world problem, for after all, I can simply walk to the bloody A/C control and flip it as needed, or open/close windows, etc. But if that type of automation were to exist and were at my fingertips (moneywise), I would get it. Wifi and Multi-node: I presume you mean "I can control from multiple places" How many places do you need to adjust your home's thermostat? Why would you possibly need to adjust your thermostat if you're not there?

How often do you need to change it? Seriously - I haven't touched my home's thermostat in probably 4 years.

Comment Re:IoT is rebranded home automation (Score 1) 96

For most consumers, IoT seems to be 99% rebranded home automation

Not quite. There is significant overlap between IoT and home automation in term of function as the former can take place in gardening, agriculture, industrial monitoring, etc. That is, the functions within home automation are a subset of IoT's functions.

But let's assume they were the same. The distinguishing characteristic is that IoT attempts to leverage existing communication/network protocols and architectures. That is a big thing (will all the good and the bad of it.)

which has always fallen flat on its face. It reminds me of 3D movies. We see it every few years then people realize it's a gimmick and we go back to business as usual.

Is it because the concept is bad, or because of prior executions? That is the question (I lean towards the later answer.)

Comment Re:In short (Score 1) 96

...the IoT is a generally stupid idea, for all the hundreds of reasons that have been repeated here ad infinitum: additional points of failure in systems that benefit very little or not at all from the 'features' added by the new connectivity.

That depends on the implementation. As it is, I wouldn't trust a IoT thermostat, specially after reading that horror story of people finding themselves without functioning heating during the cold snaps. Shit, I don't want to imagine the cost of fixing all that ice-busted plumbing.

With that said, I would love to see a multi-node thermostat that is affordable (and secure, if it is not, fuck that), adaptive, that learns to program itself, that I can control (securely) over wi-fi, and that its default fall-back mode on software failure is to fall back to a dumb, manual mode of operation.

We are not there yet (and I am not going to volunteer my $$$ to be a beta tester for an industry that doesn't pay attention to security.) But we will be there, and I'm looking forward to it.

Comment Re: another obstacle for HSR in USA? (Score 1) 218

Definitely special problems for snowflake america not shared but other countries

My thoughts exactly. It's like if Tokyo/Yokohama and Osaka didn't have these problems. And in the event that it were impossible to create a rail system within a system, then, the solution would be to have a viable public transport system (like Tokyo has between its subway lines.)

Comment Re:The one lesson developers should learn (Score 1) 39

The only issue with Parse was it was developed, hosted and run by another party.

That's actually a really big issue. I would hope that people would remember this in the future, but I don't have much hope since there have been many publicly documented failures of the 'cloud,' and people still think it's a good idea to depend on other people's servers.

Only if you do not have an enforceable SLA. And if you are big enough, chances are your systems are running in whole or in part in an external data center... with an SLA.

I mean, if you have a non-trivial presence, chances are you depend on Akamai CDN for performance and DoS protection, Google or Akamai analytics for, well, analytics. So right there, you have a set of vital functional requirements being performed on someone else's infrastructure, the failure of which can cause terrible financial harm to your organization.

This shit is not black and white dude.

Comment Re:The one lesson developers should learn (Score 1) 39

People like you and me want to own the whole stack from top to bottom for reasons of long term security of our business model. But people willing to ride the tidal wave and risk getting the floor yanked out from underneath them (to mix metaphors) build Candy Crush and Words with Friends and so forth.

That is a function of your security requirements as well as cash flow. Everyone wants to own the full stack, but economics makes it hard (and in many cases, just impossible.)

And just because there are applications that have more lax requirements than yours (assuming you actually operate on requirements and not on personal technological biases), that does not mean these applications are of the "Candy Crush" type.

Comment Re:The one lesson developers should learn (Score 2) 39

There's nothing wrong with depending on 3rd party tools and products. The problem is that most of the REST APIs that people are more and more dependent on are services, not traditional libraries.

If a library vendor goes out of business, I still have the last copy of the library and possibly even the source code. My product can continue to function until I find a suitable replacement. This is an acceptable cost of doing business, especially since commonly used libraries rarely just disappear.

If a service API goes down, my product is essentially bricked until I find and implement a replacement. This is one of those risks that most modern (er, young) developers don't appreciate. We haven't had a bust yet that shuts down a number of services over a relatively short period of time (hint: if you're using the service for free/at-a-cost-less-than-power-consumption or if it's not the vendor's core business, such as Parse, there's a good chance it will go away at some point). When that happens, the successful apps that relied on less successful services will be in a tough spot.

It'd be fun to do an analysis of the various API services people use and their interdependencies. I bet we'd find a few really scary single points of failure...


That is an inherent, unavoidable risk when doing distributed computing.

Comment Wrong Lesson (Score 1) 39

Is that they need to do actual programming, not just glue together scripts from a grab-bag of cloud services and hope they never change or shut down. Of course, you need actual programmers for this, not hipster script-kiddies.

You are oversimplifying. Though it is true that the developer's world is infected by script kiddies, there is a legitimate place for integration-centric glue code. Parse, or something like it would fit that bill. More precisely, if one has a sufficiently good back-end made available as a service, then why not leverage it?

Obviously there are issues in such an approach, but so is with everything. Engineering is about trade-offs - cost, security, availability, etc. I can roll my own back-end, but then I could run into logistic and accounting issues. Where do I host it? How much will it cost me? How much of a window do I have to maintain it?

If, OTH, there is/was a backend-as-a-service option that is sufficiently good for my current needs (and I'm not claiming Parse was), and I do not have existing technical/business/legal needs to roll up my own, then it makes engineering sense to use it.

And one of the reasons (not the primary, but an important one) to use such a backend-as-a-service is if it provides a coherent, simple and robust gluing API that I can script-kid (thus freeing me to deal with more important technical or business issues.) Again, I don't claim Parse is/was all that. I'm simply making an observation to one of your statements.

Comment Re: If it was easy (Score 1) 158

How do you know if something is fraudulent if you know nothing about how it works? Ditto for setting timelines, testing, etc. How do you manage something you know nothing of?

Higher-level use cases specifying legitimate transactions (as well as those that are supposed to be rejected, you know, failure cases.)

Before one even tries to code something, he/she must be able to explain it without referring to the technology being used. Otherwise, shit is bound to happen.

Comment Re:Visual vs wall of code (Score 1) 158

They way I figure it, using drag and drop to add code structures is just an eye-candied version of autocomplete in a text-based IDE, and it goes back to the original post: If they don't know what they are doing, they will suck at coding.

Does it matter at this stage? These tools are typically geared to kids younger than 3-4 grade (hell, the prime target would be 1st and 2nd graders.) To me, what matters at this stage is to ignite a sense of wonder and a sense that problems can be broken down into discrete, repeatable blocks: look, I can move the character 6 steps front, then 6 steps back, and making him say hello! Repeatedly, like forever! I wonder if I can make it do something else.

That's what these tools are for.

Slashdot Top Deals

"Because he's a character who's looking for his own identity, [He-Man is] an interesting role for an actor." -- Dolph Lundgren, "actor"