But science fiction (purist definition) refers to posing questions about things that are explicitly raised by advanced science concepts. BSG is good space opera. A story told against an aesthetically interesting backdrop defined in terms of futuristic aspects, but a story that could replace it all with fantasy or even current day elements and still preserve the essence of the story.
Trek and bsg represent distinct subgenres of science fiction. Trek more frequently grappled with questions directly related to aspects of change resulting directly from technology. It wasn't as deep on that front as less mainstream material, but they did ponder some questions (how does very advanced technology affect primitive culture interaction, how do you communicate with a species with an entirely difference frame of reference, what happens when transporters inadvertently clone somewone, stuff like that).
BSG is space opera. Spiffy environment, but largely a tale that could be told without the technology. Prime example being the whole New Caprica arc, which conveniently resembled the situation in Iraq. The extraordinary bad-ass rescue mounted by the battlestar's superficially involved advanced tech, but was not deeply tackling many things inherent to coping with advances in science.
I wouldn't say any of those represents shows that 'require a minimum of brain cells to watch. I don't see the mark of intellectualism really applying to any of those.
Reaper was funny and the Devil really carried it, but it did kinda go in circles in fairly short order. Easily forgivable though, since it was funny and going around in circles isn't such a horrible thing when a series doesn't take itself seriously.
Terminator was somewhat interesting, but spread what they had too thin. It's the mark of many shows of that ilk, trying to pull off long story arcs can get tiresome when the material could be handled more succinctly without real loss. Suddenly in the last episode they hinted at maybe having some interesting place to go, but guess we won't know now.
Better Off Ted made me smirk a little, but never had me over the top entertained or anything.
I was a big fan of the first season of Heroes. There were some genuinely interesting mysteries and satisfying reveals. They really had no where to go from there but down. They really wore out the Sylar character, and never created a villain as compelling as him again. Similarly they had to nerf the most powerful good guy, and propped up Hiro moreso than I think was originally intended.
Can't comment on the other two. I will say Firefly could've gone places, but give Whedon too much leeway and he will produce an overly dragged out set of arcs.
The 'will of the people' that caused generic 'voting against whoever is in office' was no more specific than 'we want economy to be better'. It really didn't matter who was in office, 'the other guys' were going in since since voters have no confidence in the economy. It's not like the people in office said 'you know what, let's willfully aim for no improvement of the economy'. In fact, I doubt any particular measure by the government would have helped the economy that much. Between private industry being particularly unhelpful and the media constantly shooting down any optimism over the economy, not much can be done IMO.
If you say the 'will of the people' was wholly represented by the extremely vocal 'tea party' activitsts, I'd say you are too easily influenced by who speaks loudest. With or without those voices, the incumbents were going to lose.
The simple, sad fact is that the majority of people who voted blindly did straight ticket one way or another, moved to action more by the drama created around politics by the media rather than informed awareness of all the facts and evaluating whose ideas seem the most plausible way to get what the voter wants. This is not anti-republican, Democrats won last time largely on the vague charisma of Obama rather than anything else, and this time the Republicans had wins as 'the other guys' set up as opponents to the establishment that hasn't given them their expected unicorns.
LISP a bad choice as a starter language.
on
Land of Lisp
·
· Score: 4, Insightful
To get the most out of LISP, you really have to approach it with a mindset particularly distinct from most programming. It also happens to be distinct in nearly requiring recursion that is generally not part of an 'easy' getting started with programming. That and most people will club themselves over the head trying to sort out how many close parentheses are needed when they write something *particularly* 'clever'.
If in modern Windows, Powershell is a good starting point, if in Linux, Python. Unlike LISP, both yield immediately marketable skills and are easy to start toying with basics and do not require a lot of knowledge of where to go to get it running, it already exists on your platform (almost certainly).
I do agree that 'web frameworks' have mutated the relatively straightforward nature of underlying http into a frightening looking mystery to the uninitiated, but at least some in the industry are swinging back to the basics and discarding some of the oddly complex schemes over HTTP.
Thanks for expounding on my point, though I will say that the biggest FUBAR in serial space are myriads of pinouts. Most of the time when you see D-SUB 9 *male* port, it's going to act predictably.
I have seen female DSUB9 ports with odd pinouts (understandable, bendable breakable pins coming off your expensive boards instead of cheap cables is bad, but the pinouts are remarkably varied). I have seen tip/ring/sleeve, I've seen RJ45, RJ11, completely proprietary connections, and even things like physical mini-usb that is electrically just the relevant portions RS-232 mapped to the USB pins. When dealing with a varied amount of equipment, you need a whole tone of adapters to ultimately get the right pins in the right places.
The people who dismiss serial simply because it is 'old' are irritating. It represents a rare example in computing where a purpose is so thoroughly fulfilled there is no advantage to be gained from going further, and everything to lose.
Issues around software development are, in my experience, about the people, not about the process so much.
Give a group any process and it will be contorted in whatever way required to make it act the way they want, but with new buzzword compliance. Frequently with misguided attempts to adopt one hard line rule or another without really appreciating the meaning of it and just ending up with arbitrary stupid things.
The best projects I've seen are ones that didn't fret overmuch about being able to rubber-stamp their process with one of the 'big names' (the only big name in style currently being 'Agile'). However well intentioned the people writing these processes may be, they simply cannot significantly impact the nature of the people actually trying to implement them.
I think Agile would've been less vomit-inducing with any other name. Naming your process Agile just invites every project manager to jump on it based on the name alone, even if they will do everything wrong and end up with a rigid process they will still declare 'Agile', which is always good.
I'm not much on the iPad aspect, but serial ports in general are still ubiquitous in datacenters. For all the madness of pinout jumbles and baud rates, it's among the most simple circuits an embedded device or facility can have that can output sufficiently rich data for initial configuration and emergency situations. Even when booting linux on a server and you want a text-based console (e.g. for logging), nothing is as robust as a serial connection.
Now you can propose any number of 'modern' alternatives using USB or Ethernet signalling, but nothing has the degree of 'near impossible to screw up' that a simple serial controller has and serial can push 115200 easy, good enough for any manual ASCII based interaction and even a lot of programattic interaction, though the latter really should be done using network after usng the serial to unscrew up what went wrong.
I can grasp the point of server-side events (though I'm not sure it's a whole lot better than just having a vanilla HTTP request 'pending' from the client at all times to afford the server a way in if needed.
I really don't get what WebSockets buys me over any generic TCP stream. The biggest thing touted commonly is 'hey, it gets through overzealous firewalls that only allow port 80', which I think is as stupid as when SOAP advocates made the point. If any of these become sufficiently pervasive, then you'll just incur a wave of higher-layer firewalling when things go to crap.
It didn't make mistakes that closely resemble those in Telnet, tftp, ftp, smtp, it made what may be considered completely distinct 'mistakes' in retrospect.
However, if you confine the scope of HTTP use to what it was intended, it holds up pretty well. It was intended to serve up material that would ultimately manifest on a endpoint as a static document. Considerations for some server-side programmatic content tweaking based on client given cues was baked in to give better coordination between client and server and some other flexibility, but it was not intended to be the engine behind highly interactive applications 'rendered' by the server. HTTP was founded at a time when the internet at large wasn't particularly shy about developing new protocols running over TCP or UDP and I'm sure the architects of HTTP would've presumed such a usage model would have induced a new protocol rather than a mutation of HTTP over time.
Part of the whole 'REST' philosophy is to get back to the vision that HTTP targets. Strictly speaking, a RESTful implementation is supposed to eschew cookies and server maintained user sessions entirely. Every currently applicable embodiment of data is supposed to have its own *U*RL and authentication when required is HTTP auth. Thanks to Javascript a web application can still avoid popping up the inadequate browser provided login dialog as well as assembling disparate data at the client side rather than server side. It doesn't work everywhere, and often even when it does it's kinda mind warping to get used to, but it does try to use HTTP more in the manner it was archictected to be used.
1. Sure 2. stateful, stream-oriented, *and* reliable 3. HTTP designed as a stateless datagram model, but wanted reliability, so TCP got chosen for lack of a better option. SCTP if it had existed might have been a better model, but for the time the stateful stream aspect of TCP was forgiven since it could largely be ignored but reliability over UDP was not so trivial. 4. More critically, the cookie mechanism strives to add stateful aspects that cross connections. This is something infeasible with TCP. Simplest example, HTTP 'state' strives to survive events like client IP changes, server failover, client sleeping for a few hours, or just generally allowing the client to disconnect and reduce server load. TCP state can survive none of those. 5. Indeed, at least AJAX enables somewhat sane masking of this, but the only-one-request-per-response character of the protocol means a lot of things cannot be done efficiently. If HTTP had allowed arbitrary server-side HTTP responses for the duration of a persistent http connection, that would have greatly alleviated the inefficiencies that AJAX methods strive to mask.
This presumes Oracle as an entity gives a rats ass about the specific former Sun people leaving Oracle. Oracle has a certain set of goals, and whose to say that this set of people are quality 'assets' for those goals. Oracle may not really care about Solaris, Office Suites, or the viability of the Java platform as a 'community' friendly entity. There are plenty of arguments to be made why they may want to care about one or the other, but the fact is Oracle has a certain vision, wanted a subset of Sun's assets, and the rest was either a freebie not worth working to retain, or potentially considered to be 'liabilities' undercutting the bottom line. I personally think the latter is inaccurate, but we are talking about a heavily proprietary company that probably has a view of open source software as an evil to be tolerated only as much as required to get their high-margin platform in the hands of customers.
Oracle is eroding Sun's reputation amongst the technically savvy, but they may consider that crowd as uselessly stingy/self-sufficient/hard to please for the comfy margins they like to make on software and services.
How dare the customer want their life to work as straightforward as it did before the change. If entering 10/20 always meant 10/20/, the fact they lost this for the sake of 'cleaner' and using more of the DB capability is a valid complaint.
The missing piece there is why the user is interacting directly with the DB, rather than some form that takes the input, sanitizes, and does nice things like append current year if year is omitted. This way, you get to use the capabilities of the DB, provide more resiliancy in the face of mistyped or malicious input, and the user doesn't have to do more work than they are used to.
Rather than everyone getting all butt-hurt over who gets invited to/kicked out of which, just do the fork, declare, and let the world figure out which derivative actually delivers the 'better' product. I personally wish they could get a better name than either OpenOffice.org or LibreOffice (unimaginative, trite, insipid names the both of them), but the name matters less than the actual project.
In short, if you want to go to 'LibreOffice', go. If you don't, don't. It's healthier for both projects if key people don't try to play nice and try to direct both. Watching and borrowing each other as licensing permits, fine, but it should be a pull model, not a murky model of shared but not identical leadership. If LibreOffice was going to be the Fedora and OpenOffice.org be the RHEL, that's one thing, but they have superficially obvious political conflicts that should be sufficient for this course to be obvious. Don't get attached to the name or leadership of the project you think is screwing up, just go and do better if you can.
In terms of being sad at the loss of the name 'OpenOffice.org', suck it up and come up with a better name (easy enough). Ethereal/Wireshark was self-evident so fast and the 'branding' change didn't significantly derail the userbase. For a more mainstream example, Netscape->Mozilla->(phoenix/firebird/Firefox) brand transitions happened pretty quickly (though the intent in that case was to supplement in each generation rather than replace, the market made it obvious quickly there wasn't room for both).
It is a GUI problem. You can do spot manipulations with GUI, but if you have a complex mass update, that's not particularly feasible in a GUI. Try changing all the spaces to underscores in a directory tree with 2,000 files. With GUI, possible eventually, with cli, trivial. For AD, mass script updates are very common.
Just as programming is textual due to the complexities required, sometimes administration exceeds the complexity a GUI can represent.
YaST over SSH in not CLI, it's TUI. The important difference is CLI is scriptable, TUI has the lack of scriptability of a GUI, but the bandwidth characteristics of CLI.
I think it's a nice example of how something running in a text-only mode is not necessarily a sufficient improvement over GUI.
I would normally agree, but it bears loud repeating in the face of many development groups wanting to emphasize cli capability being overriden by marketing departments that seem to think a CLI is an obsolete thing from the 70s no one wants in their modern product. These marketing types dictate where effort is invested, and some even go so far as to forbid a CLI. It is important that people loudly proclaim their preference and need for a CLI in the face of such an environment.
You missed the part where every major WinMo manufacturer of significance already ships more Linux based (Android) phones. If they were that desperate for indemnification, they would have avoided Android completely rather than releasing on both platforms.
Had not heard of that at all, and after some reading, it really looks like the right way to go. I'd be perfectly content with that if it works as promised and trade my IPv4 address in for a/56 in a heartbeat (I really really want at least a/56, I'm just that greedy, even though I'll probably only use one/64 out of laziness)
The problem is that every one of those sites is IPv4 accessible. IPv6 doesn't have any *exclusive* content. You can do google, facebook, netflix, and back to mac in an IPv4 only scenario. There is, however, tons of IPv4 only traffic.
So I reiterate, if I take my IPv4 connection and go through the trouble of a tunnel broker to get IPv6 as well, I haven't gained anything additional of significant value, except going through more contorted internet routes than I would for IPv4.
The problem here is that IPv6 doesn't buy the client anything other than a dancing turtle. So long as everyone *must* have an IPv4 address to meaningfully participate in the internet, IPv6 will be nothing more than a hassle for everyone down the chain, only offset by academic curiosity. Giving people tunnels that require IPv4 to operate does nothing to address the base adoption problem.
Your subject line though could've described a much more attractive strategy, ISPs not having to give out IPv4 addresses to houses, just IPv6 and having those addresses be able to reach pure IPv4 servers via some sort of NAT (really NPT since IP != IPv6 in more than just addressing). If Joe average could get slapped with an IPv6 address and never know the difference, that's a huge potential cost savings for the ISPs.
It seems mostly ok as a protocol if you ignore the context of being in an IPv4 world.
That said, with the IPv4 world, what problems are glaringly obvious. One is that generally, the v6 people threw out a whole lot of babies with the bathwater when they went clean slate. Also, generally, those are coming back in. In the beginning they said 'DHCP is obsolete, mDNS and stateless addressing', now they have a DHCP that is approaching the capability of DHCPv4 almost. They still need to have an interface identifier to go with the host identifier to let the DHCPv4 people get comfortable and give them all the capability they had in DHCPv4.
The other completely botched thing was providing no way for an IPv6-only host to ever talk to an IPv4-only host. They'll say it's impractical as that is a many to fewer mapping of address space and clients cannot be uniquely identified while keeping the pure vision of peer-to-peer or nothing at all in mind. However, having IPv6 hosts that are clients and only clients getting to IPv4 only servers via designated NPT (Network Protocol Translation) gateways would have enabled a great great mass of clients to shuffle right over to IPv6 without a horrible experience. I propose that this is still quite possible if the right people drove it.
The first is a matter of general maturity, but currently things are good enough for most. The rest require adoption to really drive change. The second aspect I also don't view as unfixable, it can still be done today, if the IPv6 leaders extract their heads from their asses and compromise on 'vision' for praticality, comforted somewhat by the knowledge that IPv4 would eventually atrophy away in that scenario.
I know that NAT breaks peer-to-peer nature of internet that architects intended, and the 'powers that be' wanted to be pure about IPv6 and thus avoided any recommendation that would have *required* NAT (verging on not wanting it to exist at all in some cases), but if IPv6 people had leveraged NAT, the current chicken and egg situation of v4->v6 could be *greatly* mitigated.
IPv6 was done as an entirely separate network space. To assure communication to all of the 'internet', one *must* have an IPv4 address and the v6 address is optional, but not sufficient to reach much of the internet which is v4-only. They should have enabled the ISPs of the world to give out only IPv6 addresses and do carrier grade NAT to IPv4 servers. The truth of the matter is that 95% of users are 'clients' and that would have placated the masses. The other 5% being able to serve only to IPv6 clients wouldn't be so painful, if the ISPs mostly did this. Sure they may feel a little gypped, but at least there is a light at the end of the tunnel and the tunnel doesn't seem as long. Getting out of having to manage a limited resource would be great incentive to get ISPs to actually deploy v6.
As it stands, IPv4 to the edge is realistically a requirement, and an ISP has nothing to save for the foreseeable future by adding IPv6, since they can't eliminate their IPv4 management infrastructure. v6 is more work without immediate payoff so long as many servers exist on v4 only. Many servers will not go v6 so long as their clients' ISP won't go v6...
I don't know enough to say they don't provide sufficent material. I have no doubt that talented people may elect to go there, but the signal-to-noise ratio is more horrid than average on those candidates. I have not yet started to actually dismiss resumes having one of these institutions on it, but every candidate with that credential so far has made me want to.
I attribute it to: -Laxer standards to get through. All of my batches that 'successfully' made it through had extraordinarily dubious capability when it came to technical problem solving.
-People intoxicated by the 'get-rich-quick' style ads they push. Another common theme was that most showed no particular inclination to the tech industry. Sure, they try to say the 'right' things in terms of interest, but you can tell when someone is just doing it for money rather than particular interest in the field. This not only exacerbates the previous issue, it also means they are not at all likely to keep skills updated when there is time. Other candidates seem more likely to actively seek training inside work and even outside work. They will spend idle moments reading up on technical news. People not inherently interested in the field will ignore training and read fark in their idle time at work.
Not a single candidate has been turned away due to this so far, but all have been turned away for failing the skills assessment. Those degrees have rapidly joined a rather large number of 'certifications' as cash grabs by institutions with no promise of greater value of the candidate.
Slashdot Mirror
But science fiction (purist definition) refers to posing questions about things that are explicitly raised by advanced science concepts. BSG is good space opera. A story told against an aesthetically interesting backdrop defined in terms of futuristic aspects, but a story that could replace it all with fantasy or even current day elements and still preserve the essence of the story.
Trek and bsg represent distinct subgenres of science fiction. Trek more frequently grappled with questions directly related to aspects of change resulting directly from technology. It wasn't as deep on that front as less mainstream material, but they did ponder some questions (how does very advanced technology affect primitive culture interaction, how do you communicate with a species with an entirely difference frame of reference, what happens when transporters inadvertently clone somewone, stuff like that).
BSG is space opera. Spiffy environment, but largely a tale that could be told without the technology. Prime example being the whole New Caprica arc, which conveniently resembled the situation in Iraq. The extraordinary bad-ass rescue mounted by the battlestar's superficially involved advanced tech, but was not deeply tackling many things inherent to coping with advances in science.
I wouldn't say any of those represents shows that 'require a minimum of brain cells to watch. I don't see the mark of intellectualism really applying to any of those.
Reaper was funny and the Devil really carried it, but it did kinda go in circles in fairly short order. Easily forgivable though, since it was funny and going around in circles isn't such a horrible thing when a series doesn't take itself seriously.
Terminator was somewhat interesting, but spread what they had too thin. It's the mark of many shows of that ilk, trying to pull off long story arcs can get tiresome when the material could be handled more succinctly without real loss. Suddenly in the last episode they hinted at maybe having some interesting place to go, but guess we won't know now.
Better Off Ted made me smirk a little, but never had me over the top entertained or anything.
I was a big fan of the first season of Heroes. There were some genuinely interesting mysteries and satisfying reveals. They really had no where to go from there but down. They really wore out the Sylar character, and never created a villain as compelling as him again. Similarly they had to nerf the most powerful good guy, and propped up Hiro moreso than I think was originally intended.
Can't comment on the other two. I will say Firefly could've gone places, but give Whedon too much leeway and he will produce an overly dragged out set of arcs.
The 'will of the people' that caused generic 'voting against whoever is in office' was no more specific than 'we want economy to be better'. It really didn't matter who was in office, 'the other guys' were going in since since voters have no confidence in the economy. It's not like the people in office said 'you know what, let's willfully aim for no improvement of the economy'. In fact, I doubt any particular measure by the government would have helped the economy that much. Between private industry being particularly unhelpful and the media constantly shooting down any optimism over the economy, not much can be done IMO.
If you say the 'will of the people' was wholly represented by the extremely vocal 'tea party' activitsts, I'd say you are too easily influenced by who speaks loudest. With or without those voices, the incumbents were going to lose.
The simple, sad fact is that the majority of people who voted blindly did straight ticket one way or another, moved to action more by the drama created around politics by the media rather than informed awareness of all the facts and evaluating whose ideas seem the most plausible way to get what the voter wants. This is not anti-republican, Democrats won last time largely on the vague charisma of Obama rather than anything else, and this time the Republicans had wins as 'the other guys' set up as opponents to the establishment that hasn't given them their expected unicorns.
To get the most out of LISP, you really have to approach it with a mindset particularly distinct from most programming. It also happens to be distinct in nearly requiring recursion that is generally not part of an 'easy' getting started with programming. That and most people will club themselves over the head trying to sort out how many close parentheses are needed when they write something *particularly* 'clever'.
If in modern Windows, Powershell is a good starting point, if in Linux, Python. Unlike LISP, both yield immediately marketable skills and are easy to start toying with basics and do not require a lot of knowledge of where to go to get it running, it already exists on your platform (almost certainly).
I do agree that 'web frameworks' have mutated the relatively straightforward nature of underlying http into a frightening looking mystery to the uninitiated, but at least some in the industry are swinging back to the basics and discarding some of the oddly complex schemes over HTTP.
Thanks for expounding on my point, though I will say that the biggest FUBAR in serial space are myriads of pinouts. Most of the time when you see D-SUB 9 *male* port, it's going to act predictably.
I have seen female DSUB9 ports with odd pinouts (understandable, bendable breakable pins coming off your expensive boards instead of cheap cables is bad, but the pinouts are remarkably varied). I have seen tip/ring/sleeve, I've seen RJ45, RJ11, completely proprietary connections, and even things like physical mini-usb that is electrically just the relevant portions RS-232 mapped to the USB pins. When dealing with a varied amount of equipment, you need a whole tone of adapters to ultimately get the right pins in the right places.
The people who dismiss serial simply because it is 'old' are irritating. It represents a rare example in computing where a purpose is so thoroughly fulfilled there is no advantage to be gained from going further, and everything to lose.
Issues around software development are, in my experience, about the people, not about the process so much.
Give a group any process and it will be contorted in whatever way required to make it act the way they want, but with new buzzword compliance. Frequently with misguided attempts to adopt one hard line rule or another without really appreciating the meaning of it and just ending up with arbitrary stupid things.
The best projects I've seen are ones that didn't fret overmuch about being able to rubber-stamp their process with one of the 'big names' (the only big name in style currently being 'Agile'). However well intentioned the people writing these processes may be, they simply cannot significantly impact the nature of the people actually trying to implement them.
I think Agile would've been less vomit-inducing with any other name. Naming your process Agile just invites every project manager to jump on it based on the name alone, even if they will do everything wrong and end up with a rigid process they will still declare 'Agile', which is always good.
I'm not much on the iPad aspect, but serial ports in general are still ubiquitous in datacenters. For all the madness of pinout jumbles and baud rates, it's among the most simple circuits an embedded device or facility can have that can output sufficiently rich data for initial configuration and emergency situations. Even when booting linux on a server and you want a text-based console (e.g. for logging), nothing is as robust as a serial connection.
Now you can propose any number of 'modern' alternatives using USB or Ethernet signalling, but nothing has the degree of 'near impossible to screw up' that a simple serial controller has and serial can push 115200 easy, good enough for any manual ASCII based interaction and even a lot of programattic interaction, though the latter really should be done using network after usng the serial to unscrew up what went wrong.
I can grasp the point of server-side events (though I'm not sure it's a whole lot better than just having a vanilla HTTP request 'pending' from the client at all times to afford the server a way in if needed.
I really don't get what WebSockets buys me over any generic TCP stream. The biggest thing touted commonly is 'hey, it gets through overzealous firewalls that only allow port 80', which I think is as stupid as when SOAP advocates made the point. If any of these become sufficiently pervasive, then you'll just incur a wave of higher-layer firewalling when things go to crap.
It didn't make mistakes that closely resemble those in Telnet, tftp, ftp, smtp, it made what may be considered completely distinct 'mistakes' in retrospect.
However, if you confine the scope of HTTP use to what it was intended, it holds up pretty well. It was intended to serve up material that would ultimately manifest on a endpoint as a static document. Considerations for some server-side programmatic content tweaking based on client given cues was baked in to give better coordination between client and server and some other flexibility, but it was not intended to be the engine behind highly interactive applications 'rendered' by the server. HTTP was founded at a time when the internet at large wasn't particularly shy about developing new protocols running over TCP or UDP and I'm sure the architects of HTTP would've presumed such a usage model would have induced a new protocol rather than a mutation of HTTP over time.
Part of the whole 'REST' philosophy is to get back to the vision that HTTP targets. Strictly speaking, a RESTful implementation is supposed to eschew cookies and server maintained user sessions entirely. Every currently applicable embodiment of data is supposed to have its own *U*RL and authentication when required is HTTP auth. Thanks to Javascript a web application can still avoid popping up the inadequate browser provided login dialog as well as assembling disparate data at the client side rather than server side. It doesn't work everywhere, and often even when it does it's kinda mind warping to get used to, but it does try to use HTTP more in the manner it was archictected to be used.
1. Sure
2. stateful, stream-oriented, *and* reliable
3. HTTP designed as a stateless datagram model, but wanted reliability, so TCP got chosen for lack of a better option. SCTP if it had existed might have been a better model, but for the time the stateful stream aspect of TCP was forgiven since it could largely be ignored but reliability over UDP was not so trivial.
4. More critically, the cookie mechanism strives to add stateful aspects that cross connections. This is something infeasible with TCP. Simplest example, HTTP 'state' strives to survive events like client IP changes, server failover, client sleeping for a few hours, or just generally allowing the client to disconnect and reduce server load. TCP state can survive none of those.
5. Indeed, at least AJAX enables somewhat sane masking of this, but the only-one-request-per-response character of the protocol means a lot of things cannot be done efficiently. If HTTP had allowed arbitrary server-side HTTP responses for the duration of a persistent http connection, that would have greatly alleviated the inefficiencies that AJAX methods strive to mask.
This presumes Oracle as an entity gives a rats ass about the specific former Sun people leaving Oracle. Oracle has a certain set of goals, and whose to say that this set of people are quality 'assets' for those goals. Oracle may not really care about Solaris, Office Suites, or the viability of the Java platform as a 'community' friendly entity. There are plenty of arguments to be made why they may want to care about one or the other, but the fact is Oracle has a certain vision, wanted a subset of Sun's assets, and the rest was either a freebie not worth working to retain, or potentially considered to be 'liabilities' undercutting the bottom line. I personally think the latter is inaccurate, but we are talking about a heavily proprietary company that probably has a view of open source software as an evil to be tolerated only as much as required to get their high-margin platform in the hands of customers.
Oracle is eroding Sun's reputation amongst the technically savvy, but they may consider that crowd as uselessly stingy/self-sufficient/hard to please for the comfy margins they like to make on software and services.
How dare the customer want their life to work as straightforward as it did before the change. If entering 10/20 always meant 10/20/, the fact they lost this for the sake of 'cleaner' and using more of the DB capability is a valid complaint.
The missing piece there is why the user is interacting directly with the DB, rather than some form that takes the input, sanitizes, and does nice things like append current year if year is omitted. This way, you get to use the capabilities of the DB, provide more resiliancy in the face of mistyped or malicious input, and the user doesn't have to do more work than they are used to.
Rather than everyone getting all butt-hurt over who gets invited to/kicked out of which, just do the fork, declare, and let the world figure out which derivative actually delivers the 'better' product. I personally wish they could get a better name than either OpenOffice.org or LibreOffice (unimaginative, trite, insipid names the both of them), but the name matters less than the actual project.
In short, if you want to go to 'LibreOffice', go. If you don't, don't. It's healthier for both projects if key people don't try to play nice and try to direct both. Watching and borrowing each other as licensing permits, fine, but it should be a pull model, not a murky model of shared but not identical leadership. If LibreOffice was going to be the Fedora and OpenOffice.org be the RHEL, that's one thing, but they have superficially obvious political conflicts that should be sufficient for this course to be obvious. Don't get attached to the name or leadership of the project you think is screwing up, just go and do better if you can.
In terms of being sad at the loss of the name 'OpenOffice.org', suck it up and come up with a better name (easy enough). Ethereal/Wireshark was self-evident so fast and the 'branding' change didn't significantly derail the userbase. For a more mainstream example, Netscape->Mozilla->(phoenix/firebird/Firefox) brand transitions happened pretty quickly (though the intent in that case was to supplement in each generation rather than replace, the market made it obvious quickly there wasn't room for both).
It is a GUI problem. You can do spot manipulations with GUI, but if you have a complex mass update, that's not particularly feasible in a GUI. Try changing all the spaces to underscores in a directory tree with 2,000 files. With GUI, possible eventually, with cli, trivial. For AD, mass script updates are very common.
Just as programming is textual due to the complexities required, sometimes administration exceeds the complexity a GUI can represent.
YaST over SSH in not CLI, it's TUI. The important difference is CLI is scriptable, TUI has the lack of scriptability of a GUI, but the bandwidth characteristics of CLI.
I think it's a nice example of how something running in a text-only mode is not necessarily a sufficient improvement over GUI.
I would normally agree, but it bears loud repeating in the face of many development groups wanting to emphasize cli capability being overriden by marketing departments that seem to think a CLI is an obsolete thing from the 70s no one wants in their modern product. These marketing types dictate where effort is invested, and some even go so far as to forbid a CLI. It is important that people loudly proclaim their preference and need for a CLI in the face of such an environment.
You missed the part where every major WinMo manufacturer of significance already ships more Linux based (Android) phones. If they were that desperate for indemnification, they would have avoided Android completely rather than releasing on both platforms.
Had not heard of that at all, and after some reading, it really looks like the right way to go. I'd be perfectly content with that if it works as promised and trade my IPv4 address in for a /56 in a heartbeat (I really really want at least a /56, I'm just that greedy, even though I'll probably only use one /64 out of laziness)
The problem is that every one of those sites is IPv4 accessible. IPv6 doesn't have any *exclusive* content. You can do google, facebook, netflix, and back to mac in an IPv4 only scenario. There is, however, tons of IPv4 only traffic.
So I reiterate, if I take my IPv4 connection and go through the trouble of a tunnel broker to get IPv6 as well, I haven't gained anything additional of significant value, except going through more contorted internet routes than I would for IPv4.
The problem here is that IPv6 doesn't buy the client anything other than a dancing turtle. So long as everyone *must* have an IPv4 address to meaningfully participate in the internet, IPv6 will be nothing more than a hassle for everyone down the chain, only offset by academic curiosity. Giving people tunnels that require IPv4 to operate does nothing to address the base adoption problem.
Your subject line though could've described a much more attractive strategy, ISPs not having to give out IPv4 addresses to houses, just IPv6 and having those addresses be able to reach pure IPv4 servers via some sort of NAT (really NPT since IP != IPv6 in more than just addressing). If Joe average could get slapped with an IPv6 address and never know the difference, that's a huge potential cost savings for the ISPs.
It seems mostly ok as a protocol if you ignore the context of being in an IPv4 world.
That said, with the IPv4 world, what problems are glaringly obvious. One is that generally, the v6 people threw out a whole lot of babies with the bathwater when they went clean slate. Also, generally, those are coming back in. In the beginning they said 'DHCP is obsolete, mDNS and stateless addressing', now they have a DHCP that is approaching the capability of DHCPv4 almost. They still need to have an interface identifier to go with the host identifier to let the DHCPv4 people get comfortable and give them all the capability they had in DHCPv4.
The other completely botched thing was providing no way for an IPv6-only host to ever talk to an IPv4-only host. They'll say it's impractical as that is a many to fewer mapping of address space and clients cannot be uniquely identified while keeping the pure vision of peer-to-peer or nothing at all in mind. However, having IPv6 hosts that are clients and only clients getting to IPv4 only servers via designated NPT (Network Protocol Translation) gateways would have enabled a great great mass of clients to shuffle right over to IPv6 without a horrible experience. I propose that this is still quite possible if the right people drove it.
The first is a matter of general maturity, but currently things are good enough for most. The rest require adoption to really drive change. The second aspect I also don't view as unfixable, it can still be done today, if the IPv6 leaders extract their heads from their asses and compromise on 'vision' for praticality, comforted somewhat by the knowledge that IPv4 would eventually atrophy away in that scenario.
I know that NAT breaks peer-to-peer nature of internet that architects intended, and the 'powers that be' wanted to be pure about IPv6 and thus avoided any recommendation that would have *required* NAT (verging on not wanting it to exist at all in some cases), but if IPv6 people had leveraged NAT, the current chicken and egg situation of v4->v6 could be *greatly* mitigated.
IPv6 was done as an entirely separate network space. To assure communication to all of the 'internet', one *must* have an IPv4 address and the v6 address is optional, but not sufficient to reach much of the internet which is v4-only. They should have enabled the ISPs of the world to give out only IPv6 addresses and do carrier grade NAT to IPv4 servers. The truth of the matter is that 95% of users are 'clients' and that would have placated the masses. The other 5% being able to serve only to IPv6 clients wouldn't be so painful, if the ISPs mostly did this. Sure they may feel a little gypped, but at least there is a light at the end of the tunnel and the tunnel doesn't seem as long. Getting out of having to manage a limited resource would be great incentive to get ISPs to actually deploy v6.
As it stands, IPv4 to the edge is realistically a requirement, and an ISP has nothing to save for the foreseeable future by adding IPv6, since they can't eliminate their IPv4 management infrastructure. v6 is more work without immediate payoff so long as many servers exist on v4 only. Many servers will not go v6 so long as their clients' ISP won't go v6...
You don't have to tell them you have a particular degree and they'll probably never know.
Conversely, if you lie about having a degree when you do not, most companies will catch that lie and immediately cancel hiring you.
I don't know enough to say they don't provide sufficent material. I have no doubt that talented people may elect to go there, but the signal-to-noise ratio is more horrid than average on those candidates. I have not yet started to actually dismiss resumes having one of these institutions on it, but every candidate with that credential so far has made me want to.
I attribute it to:
-Laxer standards to get through. All of my batches that 'successfully' made it through had extraordinarily dubious capability when it came to technical problem solving.
-People intoxicated by the 'get-rich-quick' style ads they push. Another common theme was that most showed no particular inclination to the tech industry. Sure, they try to say the 'right' things in terms of interest, but you can tell when someone is just doing it for money rather than particular interest in the field. This not only exacerbates the previous issue, it also means they are not at all likely to keep skills updated when there is time. Other candidates seem more likely to actively seek training inside work and even outside work. They will spend idle moments reading up on technical news. People not inherently interested in the field will ignore training and read fark in their idle time at work.
Not a single candidate has been turned away due to this so far, but all have been turned away for failing the skills assessment. Those degrees have rapidly joined a rather large number of 'certifications' as cash grabs by institutions with no promise of greater value of the candidate.