[INSERT LONG ASS LIST OF FILES HERE IN SIMILAR FORMAT TO ls -l THAT SLASHDOT REFUSES TO LET ME POST]
PS C:\> Set-Location dev PS C:\dev> Get-Content _vimrc.....
How one might obtain a directory listing in a concise format is beyond me.
Ah! That is because in PowerShell, the cmdlets are more true to the Unix principle of doing one thing and do it well: The Get-ChildItem cmdlet is not in the business of formatting output; it's purpose is to find child items. And that is what it does: It finds items and passes them along the pipeline.
If objects "fall off" at the end of the pipeline, they are displayed at the console. PowerShell has a number of built-in formats for displaying various item types. In the case of file system objects (fileinfo and directoryinfo objects) they are formatted very much like what the old dir command did.
But don't let that fool you: It is still objects being passed, and you can format them any way you like.
However, in PowerShell, formatting is the responsibility of a few general formatting commands. Try piping the output of Get-ChildItem through Format-Table, Format-List, Format-Wide. There is even a Format-Custom where you can specify your own formatting.
Format-Table formats the objects in table format, i.e. each item on a separate row, with the properties as columns. You can specify which properties of the objects goes into the columns. You can group and even calculate sums.
Format-List formats items in multiple groups of lines, where each line in is a property name and a value. Again, you can specify which properties goes in the output.
BTW, Get-ChildItem has aliases ls, dir and gci. Format-Table, Format-Wide and Format-List has aliases ft, fw and fl, respectively. So if it is really such a problem that you cannot get the default format of ls, you can do
ls | fw
That is, get the child items of the current directory and format them "wide" - which is spread across multiple columns.
Now, see if you can guess what this one does:
ps | fw
If you guessed it, you are beginning to understand.
... (besides the obvious many-small-binaries unix philosophy vs the one-giant-blob windows philosophy) is that *sh is both a CLI and a scripting language.
PowerShell is not a one-giant-blob. The commands of PowerShell are all of them defined in a module. The core commands comes from a core module. The shell itself does not need "magic" commands like bash and other *sh shells do (for instance, cd could not have been implemented as a loadable command in bash - because it manipulates the environment that is not accessible from external commands).
Even the ability to navigate a file system hierarchy is loadable. PowerShell itself set up infrastructure for navigating "hierarchies" - and a file system is just one such hierarchy. Other providers/hierarchies are certificate store (think advanced keyring), registry, active directory, IIS server virtual file system, SQL server (navigate tables etc).
... is that *sh is both a CLI and a scripting language. Powershell is useful just as a scripting language.
False. PowerShell has many features aimed squarely at interactive user, and frankly there is no other shell that come close:
* Automatic metadata inference: Tab completion, automatic suggestions, syntax help, (parts of) man pages are derived automatically from the command/function definitions. Number, names and types of parameters are declared for cmdlet parameters. Even declarative validators will be picked up. When you type "man somecommand", PowerShell looks up all that information and generates up-to-date call syntax instructions along with whatever man content has been written. It works for built-in commands and functions, user defined commands/functions and even script files. Script files use a param directive to declare parameter names and types.
* Tab completion *and* automatic suggestions (intellisense - in the ISE), again generated from the metadata. Even works for your own script files without having to write completion definitions.
* Risk management. If you invoke commands with -WhatIf or -Confirm, the command will inform you what it *would have* done and inform you what it is *going to do* and ask for your consent, respectively. This is shell infrastructure and it even works for entire script files and nested scripts (when you invoke a script file with -WhatIf it will execute as if all the command invocations had been invoked with -WhatIf).
* Custom actions for warnings, errors, verbose messages and debug messages. You can pass -WarningAction Inquire (or short form -ea Inquire) to have the shell ask you whether it should continue if a command (or script) writes a warning message.
* Progess indicator and input functions infrastructure that work even across job and machine boundaries.
* Get-Credential cmdlet to *securely* obtain credentials from the user - allowing the user to prove identity by not just password, but by any authentication mechanisms available at the workstation, such as card reader, biometric devices, onetime passwords etc. Passwords are guaranteed to *NEVER* be available in memory in clear text (as opposed to bash/Linux).
* Out-Gridview (with alias ogv) lets you present a collection of objects in a GUI list and have the user pick one or many of them. The picked objects will be passed on on the commandline.
* much more
Sure you could use powershell as the CLI, but it does seriously suck.
I suspect that you have never really tried it. And I'm quite sure that you have never used the ISE - which has a command(console) pane but which also has source-level debugging, snippets, multiple script windows, multiple sessions, remote sessions etc.
Granted with bash illustrating the problems of a dual-use CLI and shell, separating the two might not be such a bad idea, but it's so much easier transitioning from shell one-lin
Doesn't see to have a real shell yet. Bash, csh, tcsh, I don't care. Windows is a gaming OS unless it can put productivity back. Otherwise it's OS X or Linux...
You, like most her, completely misunderstood what's going on. QTFA: "While the companies themselves aren't under investigation, their input is being sought because they would be required to return any unpaid taxes."
I repeat: Apple is not under investigation, they will not be fined. The worst that can happen to them is be required to pay taxes saved. It's only Ireland who is in trouble (and the other countries under investigation).
But if the Irish laws supported Apple what's the legal basis for trying to claim back taxes?
I believe that the claim is that *both* Apple and the Irish government colluded to bypass Irish laws (derived from EU directives). In that case the Irish government is also going to be in trouble, treaty-wise.
I have a feeling that we'll soon see a pattern where Microsoft, Apple, Google and more did get illegal tax-breaks by moving european HQs to Ireland. If it can be demonstrated that they colluded to keep the arrangement secrets (to avoid EU commision inquiries) and that Apple et al thus should have known they did not comply with EU law, they could - and should - be in trouble.
Apple has a big coffer - so naturally that is where the EU commision will look first. I doubt that there is political will to risk the statibily of the Irish economy by forcing fines on Ireland.
Ireland is a leech, just like Luxembourg, Switzerland, Lichtenstein, the Channel Islands etc.
Second of all, whether the programming language is bad or not is totally not relevant.
On the contrary, it is deeply relevant. As long as you manipulate simple values you can do so pretty safely, even with a single-type (text) language like bash. But the second you also represent code as a value, you are setting yourself up for security problems.
This goes deeper than bash: All of the POSIX-like shells were always dangerous in the way file names and other parameters were passed to commands. Miss a proper quoting and you set yourself up for injection through a simple filename (one with a few unusual characters).
Admittedly, bash has taken it a bit further and wanted a way to allow passing functions to subshells. Again, it was a way to mitigate an inherent limitation with *sh shells: The way every command on a pipeline was executed in its own process and thus could not leverage functions and other constructs from the ultimate parent shell.
But the real problem is lack of strong types. As I said above, strong types are not terribly important (but can still help) as long as you manipulate simple values. But when those values can include executable content, knowing what type a passed parameter is supposed to be (string or code?) become a security feature.
In PowerShell you have advanced scripting where functions can be invoked from nested scopes. But in PowerShell, script blocks is a separate type. Nowhere will a function or cmdlet just execute a string, except for the cmdlet called Invoke-Expression which is roughly equivalent to bash eval. You have to ask for it to interpret a string as code. bash also has an eval function, but parameters passed to utilities such as find can also execute text!
What makes you think Windows doesn't have problems like this?
They did. But it is a long time since that last vulnerability on this scale. Following the embarrassing Nimda and Code Red (and many vulnerabilities in IIS), Microsoft started it's "security push". The central part of that is the Secure Development Lifecycle (SDL) which as a collection of processes, methodologies, tooling, mandatory education, guidance and mandatory threat modelling, reviews and auditing.
The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public.
That all fine and dandy. Only, these bugs (the original Shellshock and these later) have existed for 22+ years! During all that time, nobody (we hope) "reviewed the code and found problems". So, if there were any third parties looking at the source, they failed miserably (or sold exploit information on the black market).
Look, there have been bugs found in old MS code as well. A few years back there was a vulnerability in the old DOS emulation code.
It is time to let the myth of the many eyes die. The community is not going to help you by reviewing code unless you *pay* them to do so. It is the most boring discipline of developing code, and nobody does it out of interest.
A company like Microsoft can *pay* people to review and audit code. A big part of SDL is exactly those supporting roles and checks/gates. The open source community must wake up and set up foundations OpenSSL style and start asking those who reap the biggest benefits for some funding.
Also, fixes were pushed out within hours of notification.
Do you really want to go there, given the incomplete patches and host of related problems which could have been found had the maintainers taken more time?
Part of SDL in Microsoft is exactly a process where, when a vulnerability has been reported, they must take time to analyze if there are related or similar vulnerabilities, what impact a patch could have. On top of that they have a gigantic test farm where they test for compatibility with a huge number of popular software applications.
Essentially, what Microsoft does *internally* and prior to releasing information on the bug, is now what for bash takes place *externally* (external security researchers) and *after* the vulnerability info was released.
Look at it this way. BASH has had this problem evidently for years and there haven't been any exploits. It was discovered by researchers analyzing the code. In an MSoft world, where nobody has access to the code but MSoft, the public finds out about security holes after they have been exploited.
No no no no. This bash problem was discovered by someone trying to see if you could pass a lambda (an anonymous function) from a bash shell instance to a subshell. He then noticed some weirdness and investigated.
After the bug has become known, security "researchers" homed in on the bash interpreter. Still from *the outside* (i.e. NOT looking at the source code), more vulnerabilities were found (see Tavis Ormandy's tweets).
The easiest way to find these bugs remains to just play around with bash and try to throw it off with weird syntax. And that is how these bugs are being found.
There is absolutely no evidence that having open source code makes the product more or less secure. To be honest, only the most obvious bugs are ever found by inspecting the code - which tend to be the same class of bugs that would be found with just some cursory testing.
No, the quality of the code is impacted by the quality assurance processes that surround the development process, such as testing, threat modelling, security audits, tooling, guidance etc.
There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved.
The BIG problem here is that environment variables are inherited by default by and child processes. A semi-persistent mechanism is being used (by CGI) to pass what should have been transient data.
The passed values from CGI to the command processor is intended ONLY for the command processor. This is a specification vulnerability almost on par with PHP register_globals: If you know that a certain sub-process *also* uses environment variables to pass parameters, you can poison those environment variables from the web context.
PHP register_globals was bad exactly because of this: Sometimes a script would assume that a variable having no value (e.g. "CURRENT_USER") meant that the user had not logged on; and conversely that a value meant that the user had indeed authenticated. Presto: Inject "CURRENT_USER" as a request parameter and PHP would register a global variable which would cause the test to believe that you were logged on.
The CGI way is very, very similar: Environment variables are indeed "global" and it is very difficult for the immediate receiving processor to check whether extra variables have been set (as it itself could inherit variables from its parent process).
The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.
The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.
You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.
This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).
Seems to me that there are multiple indications that the parser is quirky, ad-hoc and error-prone. Parser construction is an old discipline. Was the bash parser created by people without the proper training, and has later maintenance ignored code because it was too weird?
Citation needed. I have never seen anyone declaring Windows Server 2012 the best ever OS because of the CLI.
With respect, the above poster is replying to someone that appears to be asserting that. I suggest reading other posts higher up in the thread before wasting time writing such long replies that miss the point.
With respect, the GP of my post never asserted that. For reference this is the entire post:
We used to run linux in the server room because it was lean and easy to admin. Windows was slow, mousy, and dependencies were hellish.
Now we run Windows Server 2012 with no GUI, virtualized, and admin with powershell. We've ripped out tens of thousands of dollars of Red Hat; windows is cheaper.
Basically there aren't any linux server distros that are like Red Hat used to be before the Fedora fiasco. It seems like Red Hat today is doing a bad job of trying to be a GUI laptop distro running on server hardware. And they are letting mature stuff like PADL's LDAP modules go to seed while shipping raw, buggy stuff like SSSD, instead of maintaining the old stuff until the new is reliable enough for real world use.
There is no assertion of "all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI" in that quote, is there?
There is a certain bias towards Server 2012, but no claim of it being the best ever server OS. Much less a claim that others think it is the best ever server OS.
I suggest reading other posts higher up in the thread before writing short post that you cannot even get right.
Windows sysadmins amaze. For fifteen years I listened to them rattle on about how the GUI in Windows NT and its descendants was absolutely necessary, that it opened up servers to people who couldn't or wouldn't learn how to work from a CLI.
You are inventing a demographic that we cannot verify, then you are ascribing a position to "them" which you then proceed ridicule because of the alleged hypocritical 180. The very definition of a strawman: Create it, pretend it is real, "kill" it.
So a few server distros put the head on their installs, worked like mad dogs to build GUI and web-based management systems like Webmin, and now suddenly all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI.
Am I getting this right: Are you seriously saying that the (alleged) argument from the Windows camp was what forced server distros [to] put the head on their installs? Seriously?
and now suddenly all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI
Citation needed. I have never seen anyone declaring Windows Server 2012 the best ever OS because of the CLI.
What you may have overlooked is the fact that Windows Server from very early on had policies. Policies even existed before AD. In Unix/Linux we scripted everything, often hoping that the scripts would perform the same on every server. During all that time some 80% of what we scripted could be expressed declaratively and more robustly using policies. Policies could ensure that application packages (MSIs or EXEs) were installed (or uninstalled), that security permissions were set up correctly, could create, rename or delete accounts, files, registry entries etc. Very little could not be expressed using declarative policies - and they could even be set to use scripts.
For the parts of remote administering that were too cumbersome to create policies for, there was always scripting. Yes, Windows scripting (.bat,.vbs and the like) used to kinda suck compared to Unix/Linux - but it *was* there.
Yes, Windows always had the GUI option - even if you did not use it. That kinda sucked for the big deployments - not so much for the smaller ones where the GUI could sometimes be an efficient way to troubleshoot a misbehaving server.
Listen you fucking asshole. *nix has been running CLI longer than most people posting here have been alive.
I am sorry that I have to be the one to break this to you, but: *nix did not invent the CLI. Indeed, every OS that came before Unix *all* of them had the CLI as the main shell.
Generations of system administrators have lived and fucking died while Windows was forcing a clunky GUI toolset that you couldn't fucking script properly, and that you ended up having to go to REGEDIT and a bazillion GPO entries to fine tune.
Seem like you had trouble with the declarative way of thinking. To me, GPOs made perfect sense. It was declarative in a way that 'nix did not have until Chef and Puppet arrived. With GPOs you could describe which application packages had to be installed on which group of machines, both servers and desktops. Move the machine to another org unit or group and group policy would ensure that aqpplications were uninstalled and new ones installed to match the new provisioning. I guess you never got that.
Oh no, but Windows is so fucking cutting edge because in the last seven or eight years has developed a fucking shell that you can properly fucking script (even if the scripting language in question is a verbose and unbelievably slow executing piece of shit that is in almost every way the exact opposite of the elegance of *nix).
I assume that you are talking about PowerShell. Initially I just want to point out that yo
Certainly cool, but most of the credit goes to C# supporting LINQ & lambda functions.
The point is, that when you view events as public event EventHandler StockQuote;
you cannot use the LINQ goodness to compose events. Once you make the switch and view events as sequences where the items have not appeared yet, you enable the likes of LINQ and list comprehensions.
Mind you, these IObservable LINQ operators look like the IEnumerable counterparts - but they are all implemented quite differently. There is a beautiful duality between the two which enable us programmers to think about events the same way we think about collections.
Besides, if the so-called Reactive "movement" thinks nobody has been writing private event buffers & message lists for the past few decades then they're mistaken.
I'm with you. I'm certainly not part of any "movement" - I do not think every programming problem needs to be attacked from a "reactive" point of view. But I can recognize a good idea when I see one, and Reactive Extensions is one such good idea. And I am already aware of several places I should have used RX and LINQ instead of building complex finite state machine logic.
Another cool idea that I think this "movement" is embracing, is async. That has much more profound consequences for how we program and has been a real eye-opener. When I can program with async all the way down through multiple tiers, to the business logic that call external services or queries the database, a whole bunch of problems suddenly goes away: I no longer has to balance how many threads should serve the website, the app servers against how "idle" the threads are when waiting for a query to return or waiting for an external service to respond. When a request "waits" it yields the thread to the server so that it can be used for other requests. Once the answer arrives from the database or service, a thread is allocated to continue the request processing. The outcome is that all threads tend to become cpu bound - never idle. Which scales much, much better.
However, I still question that this is (or needs to become) a movement. It a discipline - or rather 2 related disciplines - that a good programmer should have in his/her toolbox.
As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.
What Erik Meijer discovered was that an event can be viewed as a sequence. Each occurrence of the event is an "item" of the sequence. What's why he wrote an article called "Your mouse is a database": The mouse is a sequence of multiple event types such as moves, buttons etc.
Once you start to view (and represent) events as "push" sequences interesting things start to happen: Suddenly you can *compose* events in the same way you compose collections/sequences.
Erik Meijer wrote the Active Extensions for.NET which does exactly that. Using LINQ you can transform, aggregate, group, partition, project/map, filter etc events.
Consider, for instance, stock market ticker values: Clearly you can see those as events: When a deal/offer it is an event. Multiple events is a stream/sequence. Now imagine you want to know each time a symbol has "peaked" - i.e. each time 3 consecutive values for any symbol has the maximum as the middle value. With Reactive Extensions and LINQ you would write:
var peaks = stockQuotes.GroupBy(sq => sq.Symbol).SelectMany(g => g.Buffer(3, 1).Where(IsPeak));
where IsPeak is defined as: bool IsPeak(IList<Quote> b) {
b[0].Rate < b[1].Rate && b[1].Rate > b[2].Rate; }
Explanation: 1. stockQuotes is the IObservable stream of quotes. 2. GroupBy created a new stream of multiple streams. Each time a new symbol is encountered, a new group will be added (appear in the stream); if the symbol has already been encountered the quote is added to the end of the stream for the symbol. 3. Buffer creates a "sliding" buffers (increments of 1), each with 3 items. 4. Where filters the IObservable so that only "peaks" are let through. 5. SelectMany "flattens" multiple streams into a single stream again, i.e. creates a single stream of quotes regardless of their symbol (group)
Now, this is an IObservable stream with no subscribers (observers) yet. This also means that there is no subscription at stockQuotes. But as soon as you register a subscription like this:
peaks.Subscribe(Peaked)
It starts to invoke the Peaked method with peaks consisting of lists with exactly 3 items each. And this will go on and one.
Now imagine how you would write something like that using events and event handlers? It will probably take 10 times more code and be less readable than the above. (Yes, I know that it is not entirely straightforward if you are not used to RX and LINQ).
During boot, Windows will write log entries to the TPM. Every time a module or driver is loaded, the signature, hash code etc. is written to the TPM.
When the OS is up and running a client can request the TPM to issue the collected log entries, digitally signed with a key residing in the TPM. The boot log is then sent to a "health certificate" server. The health certificate server can inspect the log (after verifying its authenticity thjrough the signature) to see if any untrusted or known malicious software was loaded during the startup process. If everything checks out OK, it can then issue a "Health certificate".
Other devices on the corporate/private net can be instructed to quaranteen servers until they can present a valid Health certificate. Ie. the TPM can play a central role in preventing malicious software from propagating on internal Networks: If a server suddenly load more drivers than expected, loads non-whitelisted drivers or directly blacklisted drivers, nobody wants to talk to it.
Do Apple have the majority of the market in smartphones and exert an undue influence on that market? Nope, they're not even the biggest player in that market. Not at all the same as Microsoft having 95% of the desktop market and Google having over 70% of the internet search market and using their market position to keep out competitors. I don't like what Apple do but if people don't like Apple's behaviour there are half a dozen other manufacturers happy to take their money instead.
In the EU you do not need to have the majority of a market to run afoul with the Commision. If you have a dominant market position and use it to unduly lock out competitors you'll get in trouble. As you should.
This reeks like Apple want to establish their own payment system as the defacto standard. And they are prepared to use their significant market share to do it. That could (and should) get them into trouble.
I've had Steam put promotional stuff in my library automatically on a couple of occasions.
Yes, but it doesn't download it to your computer automatically.
No, Steam is actually worse: I play CIV5 on occasion. It was purchased on Steam, but I start from the shortcut I asked it to create. Nevertheless, Steam creates a pop-under ad that I have to close *every* time I play the game.
The point is not that I could probably easily find the shortcut to the *real* game (and not the Steam launcher). The point is lack of respect. I already bought the game. As far as I am concerned that is a completed transaction. I have NOT asked for promotional offers.
Yeah, I noticed after posting the comment that the summary was completely wrong. But in my defence; how could I have known that a summary on Slashdot would be completely wrong?
Yes. My bad. I am sorry.
It wasn't you who pulled it out of thin air. I can see how it was implied by the submitter.
Damn. One could get the impression that submitters/editors sensationalize just to get page-clicks.
Just to have the NFL officially use your brand of tablet.
What gave you that idea? Did you just pull it out of thin air?
It covers more than that. Read the MS press release on the deal:
The agreement provides Microsoft with the rights to create exclusive interactive experiences through products such as Xbox One and Surface, transforming the way fans will experience the NFL in the years to come. The NFL on Xbox will provide fans with an all-new viewing experience through innovations around Skype and Xbox SmartGlass; an all-new, innovative fantasy football solution allowing fans to view players and live competition side by side on a single TV screen; and a personalized NFL destination featuring information about the players, teams and games fans care about most. Xbox also retains the exclusive rights to extend these interactive experiences to tablets, enabling fans to use Xbox SmartGlass technology to enhance game day.
So, basically also the license to use NFL content on XBox and tablets (I see no mention of live content - but it could be buried in the "xbox experience")
No advertising seconds, no "official phone", "official supplier" or anything, just "official tablet".
Wrong. From the press release (see above):
As part of the partnership, Surface by Microsoft branding will appear on NFL sidelines in unique ways, including on the hoods of the official on-field NFL instant replay stations. As part of the relationship, Microsoft will be granted the following designations:
Xbox remains “The Official Game Console of the NFL” and will also become “The Official Interactive Video Entertainment Console.”
Microsoft is “The Official Sideline Technology Sponsor of the NFL.”
Surface by Microsoft and Windows are “The Official Tablet and PC Operating System of the NFL.”
The agreement provides Microsoft with the rights to create exclusive interactive experiences through products such as Xbox One and Surface, transforming the way fans will experience the NFL in the years to come. The NFL on Xbox will provide fans with an all-new viewing experience through innovations around Skype and Xbox SmartGlass; an all-new, innovative fantasy football solution allowing fans to view players and live competition side by side on a single TV screen; and a personalized NFL destination featuring information about the players, teams and games fans care about most. Xbox also retains the exclusive rights to extend these interactive experiences to tablets, enabling fans to use Xbox SmartGlass technology to enhance game day.
So MS has also licensed the rights to use the NFL brand, clips etc. (could be 3D instant replay on the xbox, streaming over Skype?).
And exclusive rights for tablets. Could be a driver for Surface uptake.
And also this:
As part of the partnership, Surface by Microsoft branding will appear on NFL sidelines in unique ways, including on the hoods of the official on-field NFL instant replay stations. As part of the relationship, Microsoft will be granted the following designations:
The instant review stations are in view during some of the most tense situations of a game, with a lot of attention. Surely, that is worth money.
400.000.000 is a lot of money. I have no idea if it is too expensive or not. But it does cover more than the right to equip the sidelines with tablets.
You do understand that it takes ROOT to set the SUID bit on a file right?
You do understand what the SUID bit does when the file is owned by ROOT, right? When you run such a file, you elevate to root just to change the password. That is *vastly* more power than you need, and it is a serious danger: Just a simple bug like a buffer overflow can cause total system compromise when it allows the attacker to execute as root.
This is why you will find all SUID programs set to read only and owned by an administrative user (such as root). It is why you instruct your sysadmin staff to NEVER SUID anything w/o good reason and permission and It is also why you scan systems for SUID binaries and scripts regularly so you can find and remove such nonsense as SUID security holes.
Yes, it is because the interent danger in SUID root utilities. Now imagine a security model that does not need anything like SUID.
And if you find any unexplained SUID stuff on your box, you pull the plug on everything and start looking for where the break in happened because you've been compromised and your whole network is suspect.
Yes, but how do you audit the "explained" SUID stuff? How do a security auditor really know what a user can do, which resources (files, etc) a specific user can access, when he is allowed execute access to SUID utilities like sudo, passwd and the likes? He may think he knows what the utility does by it's name, but how does he know *what else* it can do?
What do you think of a security model where you will have to compile all utilities from audited sources, with audited compilers to make sure that users cannot access resources they are not supposed to.
See, that's the difference between a security model that protects resources and one that tries to restrict access to utilities that can manipulate every resource on the system: You cannot effectively audit such a system.
But we are talking ONE issue now which has long been known and easily avoided.
No, we are talking an issue that is the result of an inadequate security model that is incapable of securing anything but files.
Windows NT was designed with access control in place for files, devices, mailslots, pipes (named and anonymous), jobs, processes, threads, events, keyed events, event pairs, mutexes, semaphores, shared memory sections, I/O completion ports, LPC ports, waitable timers, access tokens, volumes, window stations, desktops, network shares, services, registry keys, printers, Active Directory objects, and so on. Yes Active Directory objects are in that list, because the model was designed to be extensible
We are talking you claiming that an operating system which cannot even pass the Orange Book requirements without severe redesign by NSA is more secure out of the box than an operating system which has met those requirements from day 1.
Ever wonder why they picked the [CTL][ALT][DEL] key sequence in Windows NT? Think about it... Windows has the same kinds of issues, you just don't want to think about it
The secure attention sequence is guaranteed to be non-hookable by software on the box. The reason for that is added security (that Linux lacks), not a remediation of lacking isolation. Yes, Windows has had similar (but far from as severe) problems with shatter attacks. And there's learning for you in how it was handled:
After UAC was introduced with Windows Vista it was made illegal for lower-integrity processes to send messages (or hook keyboard etc) of higher-integrity processes - even if they were running as the same user. Combined with the fact that IE ran as low-integrity it was made exceedingly difficult for an attacker to hook the kayboard or remote control other windows, even if he compromised the IE process.
However, trojan malware that users were tricked into installing as normal-integrity processes could still hook the keyboard. With Windows 7 Microsoft added to the protection: No longer can an equal-level (integrity level) process hook another process' window or keyboard. To accomodate accessibility tools which frequently need to do that, Microsoft allowed a slightly *higher* integrity level *if* and only if a certain manifest requires it and the files has been digitally signed.
The point of this is that both enhancements were achieved through the already extensible security model. Integrity levels were simply assigned SIDs. If the low-integrity SID is in your process token you are a low-integrity process.
You can *never* extend the simplistic Linux security model like this. It is forever limited to user identities. A process under Linux does not have a token - it has an effective user. It was designed with the faulty assumption that a process in all aspects could represent the user who started it. Proper tokens recognize that processes may have fewer rights, or even more rights than the user who launched it.
You have uttered unbased claims through this entire thread. Now it's time to tell the world how - specifically - the Linux mode is inherently more secure than the Windows model.
I don't run X on any "server" system I manage. Not for this reason, but for the general security concept that you don't run stuff you don't use. Good luck turning off the GUI on your windows box...
Didn't you say that you just finished off setting up a Windows Server 2008R2? And you do not know about Server Core? I sense much deceit here. (IOW: I don't believe you).
However, if you did have X running, it's only going to accept X client connections from the local machine (unless you've opened it up further). This means that any attack vector though X will have to be launched from the local box. Which means that the attacker will have to compromise the local box in some other way.
Goes to show your grasp of this security thingy. There's this security principle called isolation:
Windows has been dealing with so-called shatter attacks where rogue processes sent messages remotely controlling windows belonging to other processes. Up until Windows Vista, Windows only isolated processes belonging to different users. With Vista and MIC (Mandatory Integrity Control), processes were prohibited from sending such messages to windows of higher-integrity processes.
X based Linux distros have absolutely zero isolation. Do you have any idea how serious this is? If there is a memory corruption bug in Firefox and the process is taken over (FF does not have sandboxing), it can install a keyboard hook in X and read every single keystroke entered into any windows. That includes a terminal windows, and worse, even if you sudo to root user, the keyboard hook read every single keystroke including the sudo password.
If that's a superior security model than I have a tower in Paris you may want to invest in.
1. Unix was developed on the Digital Equipment Corp PDP-11 hardware in about 1970. Unix started as a multi-user system that supported memory segment protection between user processes and kernel space.
2. VMS followed on the next generation of DEC hardware the VAX-11780, which made it's appearance in the late 1970's. This system introduced Virtual Memory spaces for user processes. (Thus it's name Virtual Memory System) VMS was not first in being muti-user, commercially that was Unix.
3. Windows NT arrived in the late 80's, and not surprisingly ran on DEC VAX hardware as well as x86 based systems, as the chief engineer of NT came out of the VMS development team at DEC.
So NT got this idea from VMS which got it from Unix....
Unix was never implemented for PDP-11 by DEC. 3rd parties adapted several versions so that they could run on the PDP-11. A number of generations of "realtime" operating systems were developed by DEC for the PDP-11 and later the VAX-11 series.
Dave Cutler was on the teams for many of these OSes. Dave Cutler left for Microsoft to design Windows NT. Dave Cutler *never* implemented an OS for PDP-11 based on Unix. In fact, he *disliked* Unix.
And no, Unix did not invent access control. I sense that you need Unix to be some type of god-like hero. It is an operating system, and an aging one at that. Cool off.
BSOD happens when the kernel detects memory corruption. With a hybrid monolithic kernel like Windows that means all bets are off and continuing could very well case damage more damage.
Even if the memory corruption happens in an USB driver, it can overwrite critical kernel memory.
Incidentally, you *do* get more information. The kernel will initiate a kernel dump which can be investigated later.
Slashdot Mirror
Terseness??
PS C:\> Get-ChildItem
[INSERT LONG ASS LIST OF FILES HERE IN SIMILAR FORMAT TO ls -l THAT SLASHDOT REFUSES TO LET ME POST]
PS C:\> Set-Location dev .....
PS C:\dev> Get-Content _vimrc
How one might obtain a directory listing in a concise format is beyond me.
Ah! That is because in PowerShell, the cmdlets are more true to the Unix principle of doing one thing and do it well: The Get-ChildItem cmdlet is not in the business of formatting output; it's purpose is to find child items. And that is what it does: It finds items and passes them along the pipeline.
If objects "fall off" at the end of the pipeline, they are displayed at the console. PowerShell has a number of built-in formats for displaying various item types. In the case of file system objects (fileinfo and directoryinfo objects) they are formatted very much like what the old dir command did.
But don't let that fool you: It is still objects being passed, and you can format them any way you like.
However, in PowerShell, formatting is the responsibility of a few general formatting commands. Try piping the output of Get-ChildItem through Format-Table, Format-List, Format-Wide. There is even a Format-Custom where you can specify your own formatting.
Format-Table formats the objects in table format, i.e. each item on a separate row, with the properties as columns. You can specify which properties of the objects goes into the columns. You can group and even calculate sums.
Format-List formats items in multiple groups of lines, where each line in is a property name and a value. Again, you can specify which properties goes in the output.
BTW, Get-ChildItem has aliases ls, dir and gci. Format-Table, Format-Wide and Format-List has aliases ft, fw and fl, respectively. So if it is really such a problem that you cannot get the default format of ls, you can do
ls | fw
That is, get the child items of the current directory and format them "wide" - which is spread across multiple columns.
Now, see if you can guess what this one does:
ps | fw
If you guessed it, you are beginning to understand.
Now do a ls | ogv the be blown away.
... (besides the obvious many-small-binaries unix philosophy vs the one-giant-blob windows philosophy) is that *sh is both a CLI and a scripting language.
PowerShell is not a one-giant-blob. The commands of PowerShell are all of them defined in a module. The core commands comes from a core module. The shell itself does not need "magic" commands like bash and other *sh shells do (for instance, cd could not have been implemented as a loadable command in bash - because it manipulates the environment that is not accessible from external commands).
Even the ability to navigate a file system hierarchy is loadable. PowerShell itself set up infrastructure for navigating "hierarchies" - and a file system is just one such hierarchy. Other providers/hierarchies are certificate store (think advanced keyring), registry, active directory, IIS server virtual file system, SQL server (navigate tables etc).
... is that *sh is both a CLI and a scripting language. Powershell is useful just as a scripting language.
False. PowerShell has many features aimed squarely at interactive user, and frankly there is no other shell that come close:
* Automatic metadata inference: Tab completion, automatic suggestions, syntax help, (parts of) man pages are derived automatically from the command/function definitions. Number, names and types of parameters are declared for cmdlet parameters. Even declarative validators will be picked up. When you type "man somecommand", PowerShell looks up all that information and generates up-to-date call syntax instructions along with whatever man content has been written. It works for built-in commands and functions, user defined commands/functions and even script files. Script files use a param directive to declare parameter names and types.
* Tab completion *and* automatic suggestions (intellisense - in the ISE), again generated from the metadata. Even works for your own script files without having to write completion definitions.
* Risk management. If you invoke commands with -WhatIf or -Confirm, the command will inform you what it *would have* done and inform you what it is *going to do* and ask for your consent, respectively. This is shell infrastructure and it even works for entire script files and nested scripts (when you invoke a script file with -WhatIf it will execute as if all the command invocations had been invoked with -WhatIf).
* Custom actions for warnings, errors, verbose messages and debug messages. You can pass -WarningAction Inquire (or short form -ea Inquire) to have the shell ask you whether it should continue if a command (or script) writes a warning message.
* Progess indicator and input functions infrastructure that work even across job and machine boundaries.
* Get-Credential cmdlet to *securely* obtain credentials from the user - allowing the user to prove identity by not just password, but by any authentication mechanisms available at the workstation, such as card reader, biometric devices, onetime passwords etc. Passwords are guaranteed to *NEVER* be available in memory in clear text (as opposed to bash/Linux).
* Out-Gridview (with alias ogv) lets you present a collection of objects in a GUI list and have the user pick one or many of them. The picked objects will be passed on on the commandline.
* much more
Sure you could use powershell as the CLI, but it does seriously suck.
I suspect that you have never really tried it. And I'm quite sure that you have never used the ISE - which has a command(console) pane but which also has source-level debugging, snippets, multiple script windows, multiple sessions, remote sessions etc.
Granted with bash illustrating the problems of a dual-use CLI and shell, separating the two might not be such a bad idea, but it's so much easier transitioning from shell one-lin
Doesn't see to have a real shell yet. Bash, csh, tcsh, I don't care. Windows is a gaming OS unless it can put productivity back. Otherwise it's OS X or Linux...
PowerShell beats anything *sh on consistency, terseness, expressiveness, risk management, integration, remoting, job control, interactive assistance.
And it is not as dangerous :-)
You, like most her, completely misunderstood what's going on. QTFA: "While the companies themselves aren't under investigation, their input is being sought because they would be required to return any unpaid taxes."
I repeat: Apple is not under investigation, they will not be fined. The worst that can happen to them is be required to pay taxes saved. It's only Ireland who is in trouble (and the other countries under investigation).
Thanks. I stand corrected :-)
But if the Irish laws supported Apple what's the legal basis for trying to claim back taxes?
I believe that the claim is that *both* Apple and the Irish government colluded to bypass Irish laws (derived from EU directives). In that case the Irish government is also going to be in trouble, treaty-wise.
I have a feeling that we'll soon see a pattern where Microsoft, Apple, Google and more did get illegal tax-breaks by moving european HQs to Ireland. If it can be demonstrated that they colluded to keep the arrangement secrets (to avoid EU commision inquiries) and that Apple et al thus should have known they did not comply with EU law, they could - and should - be in trouble.
Apple has a big coffer - so naturally that is where the EU commision will look first. I doubt that there is political will to risk the statibily of the Irish economy by forcing fines on Ireland.
Ireland is a leech, just like Luxembourg, Switzerland, Lichtenstein, the Channel Islands etc.
Second of all, whether the programming language is bad or not is totally not relevant.
On the contrary, it is deeply relevant. As long as you manipulate simple values you can do so pretty safely, even with a single-type (text) language like bash. But the second you also represent code as a value, you are setting yourself up for security problems.
This goes deeper than bash: All of the POSIX-like shells were always dangerous in the way file names and other parameters were passed to commands. Miss a proper quoting and you set yourself up for injection through a simple filename (one with a few unusual characters).
Admittedly, bash has taken it a bit further and wanted a way to allow passing functions to subshells. Again, it was a way to mitigate an inherent limitation with *sh shells: The way every command on a pipeline was executed in its own process and thus could not leverage functions and other constructs from the ultimate parent shell.
But the real problem is lack of strong types. As I said above, strong types are not terribly important (but can still help) as long as you manipulate simple values. But when those values can include executable content, knowing what type a passed parameter is supposed to be (string or code?) become a security feature.
In PowerShell you have advanced scripting where functions can be invoked from nested scopes. But in PowerShell, script blocks is a separate type. Nowhere will a function or cmdlet just execute a string, except for the cmdlet called Invoke-Expression which is roughly equivalent to bash eval. You have to ask for it to interpret a string as code. bash also has an eval function, but parameters passed to utilities such as find can also execute text!
What makes you think Windows doesn't have problems like this?
They did. But it is a long time since that last vulnerability on this scale. Following the embarrassing Nimda and Code Red (and many vulnerabilities in IIS), Microsoft started it's "security push". The central part of that is the Secure Development Lifecycle (SDL) which as a collection of processes, methodologies, tooling, mandatory education, guidance and mandatory threat modelling, reviews and auditing.
The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public.
That all fine and dandy. Only, these bugs (the original Shellshock and these later) have existed for 22+ years! During all that time, nobody (we hope) "reviewed the code and found problems". So, if there were any third parties looking at the source, they failed miserably (or sold exploit information on the black market).
Look, there have been bugs found in old MS code as well. A few years back there was a vulnerability in the old DOS emulation code.
It is time to let the myth of the many eyes die. The community is not going to help you by reviewing code unless you *pay* them to do so. It is the most boring discipline of developing code, and nobody does it out of interest.
A company like Microsoft can *pay* people to review and audit code. A big part of SDL is exactly those supporting roles and checks/gates. The open source community must wake up and set up foundations OpenSSL style and start asking those who reap the biggest benefits for some funding.
Also, fixes were pushed out within hours of notification.
Do you really want to go there, given the incomplete patches and host of related problems which could have been found had the maintainers taken more time?
Part of SDL in Microsoft is exactly a process where, when a vulnerability has been reported, they must take time to analyze if there are related or similar vulnerabilities, what impact a patch could have. On top of that they have a gigantic test farm where they test for compatibility with a huge number of popular software applications.
Essentially, what Microsoft does *internally* and prior to releasing information on the bug, is now what for bash takes place *externally* (external security researchers) and *after* the vulnerability info was released.
Look at it this way. BASH has had this problem evidently for years and there haven't been any exploits. It was discovered by researchers analyzing the code. In an MSoft world, where nobody has access to the code but MSoft, the public finds out about security holes after they have been exploited.
No no no no. This bash problem was discovered by someone trying to see if you could pass a lambda (an anonymous function) from a bash shell instance to a subshell. He then noticed some weirdness and investigated.
After the bug has become known, security "researchers" homed in on the bash interpreter. Still from *the outside* (i.e. NOT looking at the source code), more vulnerabilities were found (see Tavis Ormandy's tweets).
The easiest way to find these bugs remains to just play around with bash and try to throw it off with weird syntax. And that is how these bugs are being found.
There is absolutely no evidence that having open source code makes the product more or less secure. To be honest, only the most obvious bugs are ever found by inspecting the code - which tend to be the same class of bugs that would be found with just some cursory testing.
No, the quality of the code is impacted by the quality assurance processes that surround the development process, such as testing, threat modelling, security audits, tooling, guidance etc.
There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved.
The BIG problem here is that environment variables are inherited by default by and child processes. A semi-persistent mechanism is being used (by CGI) to pass what should have been transient data.
The passed values from CGI to the command processor is intended ONLY for the command processor. This is a specification vulnerability almost on par with PHP register_globals: If you know that a certain sub-process *also* uses environment variables to pass parameters, you can poison those environment variables from the web context.
PHP register_globals was bad exactly because of this: Sometimes a script would assume that a variable having no value (e.g. "CURRENT_USER") meant that the user had not logged on; and conversely that a value meant that the user had indeed authenticated. Presto: Inject "CURRENT_USER" as a request parameter and PHP would register a global variable which would cause the test to believe that you were logged on.
The CGI way is very, very similar: Environment variables are indeed "global" and it is very difficult for the immediate receiving processor to check whether extra variables have been set (as it itself could inherit variables from its parent process).
The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.
The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.
You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.
This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).
Seems to me that there are multiple indications that the parser is quirky, ad-hoc and error-prone. Parser construction is an old discipline. Was the bash parser created by people without the proper training, and has later maintenance ignored code because it was too weird?
With respect, the above poster is replying to someone that appears to be asserting that. I suggest reading other posts higher up in the thread before wasting time writing such long replies that miss the point.
With respect, the GP of my post never asserted that. For reference this is the entire post:
We used to run linux in the server room because it was lean and easy to admin. Windows was slow, mousy, and dependencies were hellish.
Now we run Windows Server 2012 with no GUI, virtualized, and admin with powershell. We've ripped out tens of thousands of dollars of Red Hat; windows is cheaper.
Basically there aren't any linux server distros that are like Red Hat used to be before the Fedora fiasco. It seems like Red Hat today is doing a bad job of trying to be a GUI laptop distro running on server hardware. And they are letting mature stuff like PADL's LDAP modules go to seed while shipping raw, buggy stuff like SSSD, instead of maintaining the old stuff until the new is reliable enough for real world use.
There is no assertion of "all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI" in that quote, is there?
There is a certain bias towards Server 2012, but no claim of it being the best ever server OS. Much less a claim that others think it is the best ever server OS.
I suggest reading other posts higher up in the thread before writing short post that you cannot even get right.
Windows sysadmins amaze. For fifteen years I listened to them rattle on about how the GUI in Windows NT and its descendants was absolutely necessary, that it opened up servers to people who couldn't or wouldn't learn how to work from a CLI.
You are inventing a demographic that we cannot verify, then you are ascribing a position to "them" which you then proceed ridicule because of the alleged hypocritical 180. The very definition of a strawman: Create it, pretend it is real, "kill" it.
So a few server distros put the head on their installs, worked like mad dogs to build GUI and web-based management systems like Webmin, and now suddenly all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI.
Am I getting this right: Are you seriously saying that the (alleged) argument from the Windows camp was what forced server distros [to] put the head on their installs? Seriously?
and now suddenly all those Windows sysadmin flunkies are declaring Server 2012 is the bestest ever because you can run in headless with a CLI
Citation needed. I have never seen anyone declaring Windows Server 2012 the best ever OS because of the CLI.
What you may have overlooked is the fact that Windows Server from very early on had policies. Policies even existed before AD. In Unix/Linux we scripted everything, often hoping that the scripts would perform the same on every server.
During all that time some 80% of what we scripted could be expressed declaratively and more robustly using policies. Policies could ensure that application packages (MSIs or EXEs) were installed (or uninstalled), that security permissions were set up correctly, could create, rename or delete accounts, files, registry entries etc.
Very little could not be expressed using declarative policies - and they could even be set to use scripts.
For the parts of remote administering that were too cumbersome to create policies for, there was always scripting. Yes, Windows scripting (.bat, .vbs and the like) used to kinda suck compared to Unix/Linux - but it *was* there.
Yes, Windows always had the GUI option - even if you did not use it. That kinda sucked for the big deployments - not so much for the smaller ones where the GUI could sometimes be an efficient way to troubleshoot a misbehaving server.
Listen you fucking asshole. *nix has been running CLI longer than most people posting here have been alive.
I am sorry that I have to be the one to break this to you, but: *nix did not invent the CLI. Indeed, every OS that came before Unix *all* of them had the CLI as the main shell.
Generations of system administrators have lived and fucking died while Windows was forcing a clunky GUI toolset that you couldn't fucking script properly, and that you ended up having to go to REGEDIT and a bazillion GPO entries to fine tune.
Seem like you had trouble with the declarative way of thinking. To me, GPOs made perfect sense. It was declarative in a way that 'nix did not have until Chef and Puppet arrived. With GPOs you could describe which application packages had to be installed on which group of machines, both servers and desktops.
Move the machine to another org unit or group and group policy would ensure that aqpplications were uninstalled and new ones installed to match the new provisioning. I guess you never got that.
Oh no, but Windows is so fucking cutting edge because in the last seven or eight years has developed a fucking shell that you can properly fucking script (even if the scripting language in question is a verbose and unbelievably slow executing piece of shit that is in almost every way the exact opposite of the elegance of *nix).
I assume that you are talking about PowerShell. Initially I just want to point out that yo
Certainly cool, but most of the credit goes to C# supporting LINQ & lambda functions.
The point is, that when you view events as
public event EventHandler StockQuote;
you cannot use the LINQ goodness to compose events. Once you make the switch and view events as sequences where the items have not appeared yet, you enable the likes of LINQ and list comprehensions.
Mind you, these IObservable LINQ operators look like the IEnumerable counterparts - but they are all implemented quite differently. There is a beautiful duality between the two which enable us programmers to think about events the same way we think about collections.
Besides, if the so-called Reactive "movement" thinks nobody has been writing private event buffers & message lists for the past few decades then they're mistaken.
I'm with you. I'm certainly not part of any "movement" - I do not think every programming problem needs to be attacked from a "reactive" point of view. But I can recognize a good idea when I see one, and Reactive Extensions is one such good idea. And I am already aware of several places I should have used RX and LINQ instead of building complex finite state machine logic.
Another cool idea that I think this "movement" is embracing, is async. That has much more profound consequences for how we program and has been a real eye-opener. When I can program with async all the way down through multiple tiers, to the business logic that call external services or queries the database, a whole bunch of problems suddenly goes away: I no longer has to balance how many threads should serve the website, the app servers against how "idle" the threads are when waiting for a query to return or waiting for an external service to respond. When a request "waits" it yields the thread to the server so that it can be used for other requests. Once the answer arrives from the database or service, a thread is allocated to continue the request processing. The outcome is that all threads tend to become cpu bound - never idle. Which scales much, much better.
However, I still question that this is (or needs to become) a movement. It a discipline - or rather 2 related disciplines - that a good programmer should have in his/her toolbox.
As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.
What Erik Meijer discovered was that an event can be viewed as a sequence. Each occurrence of the event is an "item" of the sequence. What's why he wrote an article called "Your mouse is a database": The mouse is a sequence of multiple event types such as moves, buttons etc.
Once you start to view (and represent) events as "push" sequences interesting things start to happen: Suddenly you can *compose* events in the same way you compose collections/sequences.
Erik Meijer wrote the Active Extensions for .NET which does exactly that. Using LINQ you can transform, aggregate, group, partition, project/map, filter etc events.
Consider, for instance, stock market ticker values: Clearly you can see those as events: When a deal/offer it is an event. Multiple events is a stream/sequence. Now imagine you want to know each time a symbol has "peaked" - i.e. each time 3 consecutive values for any symbol has the maximum as the middle value. With Reactive Extensions and LINQ you would write:
var peaks = stockQuotes.GroupBy(sq => sq.Symbol).SelectMany(g => g.Buffer(3, 1).Where(IsPeak));
where IsPeak is defined as:
bool IsPeak(IList<Quote> b) {
b[0].Rate < b[1].Rate && b[1].Rate > b[2].Rate;
}
Explanation:
1. stockQuotes is the IObservable stream of quotes.
2. GroupBy created a new stream of multiple streams. Each time a new symbol is encountered, a new group will be added (appear in the stream); if the symbol has already been encountered the quote is added to the end of the stream for the symbol.
3. Buffer creates a "sliding" buffers (increments of 1), each with 3 items.
4. Where filters the IObservable so that only "peaks" are let through.
5. SelectMany "flattens" multiple streams into a single stream again, i.e. creates a single stream of quotes regardless of their symbol (group)
Now, this is an IObservable stream with no subscribers (observers) yet. This also means that there is no subscription at stockQuotes. But as soon as you register a subscription like this:
peaks.Subscribe(Peaked)
It starts to invoke the Peaked method with peaks consisting of lists with exactly 3 items each. And this will go on and one.
Now imagine how you would write something like that using events and event handlers? It will probably take 10 times more code and be less readable than the above. (Yes, I know that it is not entirely straightforward if you are not used to RX and LINQ).
During boot, Windows will write log entries to the TPM. Every time a module or driver is loaded, the signature, hash code etc. is written to the TPM.
When the OS is up and running a client can request the TPM to issue the collected log entries, digitally signed with a key residing in the TPM. The boot log is then sent to a "health certificate" server. The health certificate server can inspect the log (after verifying its authenticity thjrough the signature) to see if any untrusted or known malicious software was loaded during the startup process. If everything checks out OK, it can then issue a "Health certificate".
Other devices on the corporate/private net can be instructed to quaranteen servers until they can present a valid Health certificate. Ie. the TPM can play a central role in preventing malicious software from propagating on internal Networks: If a server suddenly load more drivers than expected, loads non-whitelisted drivers or directly blacklisted drivers, nobody wants to talk to it.
Do Apple have the majority of the market in smartphones and exert an undue influence on that market? Nope, they're not even the biggest player in that market. Not at all the same as Microsoft having 95% of the desktop market and Google having over 70% of the internet search market and using their market position to keep out competitors. I don't like what Apple do but if people don't like Apple's behaviour there are half a dozen other manufacturers happy to take their money instead.
In the EU you do not need to have the majority of a market to run afoul with the Commision. If you have a dominant market position and use it to unduly lock out competitors you'll get in trouble. As you should.
This reeks like Apple want to establish their own payment system as the defacto standard. And they are prepared to use their significant market share to do it. That could (and should) get them into trouble.
I've had Steam put promotional stuff in my library automatically on a couple of occasions.
Yes, but it doesn't download it to your computer automatically.
No, Steam is actually worse: I play CIV5 on occasion. It was purchased on Steam, but I start from the shortcut I asked it to create. Nevertheless, Steam creates a pop-under ad that I have to close *every* time I play the game.
The point is not that I could probably easily find the shortcut to the *real* game (and not the Steam launcher). The point is lack of respect. I already bought the game. As far as I am concerned that is a completed transaction. I have NOT asked for promotional offers.
Yeah, I noticed after posting the comment that the summary was completely wrong.
But in my defence; how could I have known that a summary on Slashdot would be completely wrong?
Yes. My bad. I am sorry.
It wasn't you who pulled it out of thin air. I can see how it was implied by the submitter.
Damn. One could get the impression that submitters/editors sensationalize just to get page-clicks.
Just to have the NFL officially use your brand of tablet.
What gave you that idea? Did you just pull it out of thin air?
It covers more than that. Read the MS press release on the deal:
So, basically also the license to use NFL content on XBox and tablets (I see no mention of live content - but it could be buried in the "xbox experience")
No advertising seconds, no "official phone", "official supplier" or anything, just "official tablet".
Wrong. From the press release (see above):
It is not just for "product placement", though.
From Microsofts press release on the deal:
The agreement provides Microsoft with the rights to create exclusive interactive experiences through products such as Xbox One and Surface, transforming the way fans will experience the NFL in the years to come. The NFL on Xbox will provide fans with an all-new viewing experience through innovations around Skype and Xbox SmartGlass; an all-new, innovative fantasy football solution allowing fans to view players and live competition side by side on a single TV screen; and a personalized NFL destination featuring information about the players, teams and games fans care about most. Xbox also retains the exclusive rights to extend these interactive experiences to tablets, enabling fans to use Xbox SmartGlass technology to enhance game day.
So MS has also licensed the rights to use the NFL brand, clips etc. (could be 3D instant replay on the xbox, streaming over Skype?).
And exclusive rights for tablets. Could be a driver for Surface uptake.
And also this:
As part of the partnership, Surface by Microsoft branding will appear on NFL sidelines in unique ways, including on the hoods of the official on-field NFL instant replay stations. As part of the relationship, Microsoft will be granted the following designations:
The instant review stations are in view during some of the most tense situations of a game, with a lot of attention. Surely, that is worth money.
400.000.000 is a lot of money. I have no idea if it is too expensive or not. But it does cover more than the right to equip the sidelines with tablets.
You do understand that it takes ROOT to set the SUID bit on a file right?
You do understand what the SUID bit does when the file is owned by ROOT, right? When you run such a file, you elevate to root just to change the password. That is *vastly* more power than you need, and it is a serious danger: Just a simple bug like a buffer overflow can cause total system compromise when it allows the attacker to execute as root.
This is why you will find all SUID programs set to read only and owned by an administrative user (such as root). It is why you instruct your sysadmin staff to NEVER SUID anything w/o good reason and permission and It is also why you scan systems for SUID binaries and scripts regularly so you can find and remove such nonsense as SUID security holes.
Yes, it is because the interent danger in SUID root utilities. Now imagine a security model that does not need anything like SUID.
And if you find any unexplained SUID stuff on your box, you pull the plug on everything and start looking for where the break in happened because you've been compromised and your whole network is suspect.
Yes, but how do you audit the "explained" SUID stuff? How do a security auditor really know what a user can do, which resources (files, etc) a specific user can access, when he is allowed execute access to SUID utilities like sudo, passwd and the likes? He may think he knows what the utility does by it's name, but how does he know *what else* it can do?
What do you think of a security model where you will have to compile all utilities from audited sources, with audited compilers to make sure that users cannot access resources they are not supposed to.
See, that's the difference between a security model that protects resources and one that tries to restrict access to utilities that can manipulate every resource on the system: You cannot effectively audit such a system.
But we are talking ONE issue now which has long been known and easily avoided.
No, we are talking an issue that is the result of an inadequate security model that is incapable of securing anything but files.
Windows NT was designed with access control in place for files, devices, mailslots, pipes (named and anonymous), jobs, processes, threads, events, keyed events, event pairs, mutexes, semaphores, shared memory sections, I/O completion ports, LPC ports, waitable timers, access tokens, volumes, window stations, desktops, network shares, services, registry keys, printers, Active Directory objects, and so on. Yes Active Directory objects are in that list, because the model was designed to be extensible
We are talking you claiming that an operating system which cannot even pass the Orange Book requirements without severe redesign by NSA is more secure out of the box than an operating system which has met those requirements from day 1.
Ever wonder why they picked the [CTL][ALT][DEL] key sequence in Windows NT? Think about it... Windows has the same kinds of issues, you just don't want to think about it
The secure attention sequence is guaranteed to be non-hookable by software on the box. The reason for that is added security (that Linux lacks), not a remediation of lacking isolation. Yes, Windows has had similar (but far from as severe) problems with shatter attacks. And there's learning for you in how it was handled:
After UAC was introduced with Windows Vista it was made illegal for lower-integrity processes to send messages (or hook keyboard etc) of higher-integrity processes - even if they were running as the same user. Combined with the fact that IE ran as low-integrity it was made exceedingly difficult for an attacker to hook the kayboard or remote control other windows, even if he compromised the IE process.
However, trojan malware that users were tricked into installing as normal-integrity processes could still hook the keyboard. With Windows 7 Microsoft added to the protection: No longer can an equal-level (integrity level) process hook another process' window or keyboard. To accomodate accessibility tools which frequently need to do that, Microsoft allowed a slightly *higher* integrity level *if* and only if a certain manifest requires it and the files has been digitally signed.
The point of this is that both enhancements were achieved through the already extensible security model. Integrity levels were simply assigned SIDs. If the low-integrity SID is in your process token you are a low-integrity process.
You can *never* extend the simplistic Linux security model like this. It is forever limited to user identities. A process under Linux does not have a token - it has an effective user. It was designed with the faulty assumption that a process in all aspects could represent the user who started it. Proper tokens recognize that processes may have fewer rights, or even more rights than the user who launched it.
You have uttered unbased claims through this entire thread. Now it's time to tell the world how - specifically - the Linux mode is inherently more secure than the Windows model.
I don't run X on any "server" system I manage. Not for this reason, but for the general security concept that you don't run stuff you don't use. Good luck turning off the GUI on your windows box...
Didn't you say that you just finished off setting up a Windows Server 2008R2? And you do not know about Server Core? I sense much deceit here. (IOW: I don't believe you).
However, if you did have X running, it's only going to accept X client connections from the local machine (unless you've opened it up further). This means that any attack vector though X will have to be launched from the local box. Which means that the attacker will have to compromise the local box in some other way.
Goes to show your grasp of this security thingy. There's this security principle called isolation:
Windows has been dealing with so-called shatter attacks where rogue processes sent messages remotely controlling windows belonging to other processes. Up until Windows Vista, Windows only isolated processes belonging to different users. With Vista and MIC (Mandatory Integrity Control), processes were prohibited from sending such messages to windows of higher-integrity processes.
X based Linux distros have absolutely zero isolation. Do you have any idea how serious this is? If there is a memory corruption bug in Firefox and the process is taken over (FF does not have sandboxing), it can install a keyboard hook in X and read every single keystroke entered into any windows. That includes a terminal windows, and worse, even if you sudo to root user, the keyboard hook read every single keystroke including the sudo password.
If that's a superior security model than I have a tower in Paris you may want to invest in.
The progression goes like this..
1. Unix was developed on the Digital Equipment Corp PDP-11 hardware in about 1970. Unix started as a multi-user system that supported memory segment protection between user processes and kernel space.
2. VMS followed on the next generation of DEC hardware the VAX-11780, which made it's appearance in the late 1970's. This system introduced Virtual Memory spaces for user processes. (Thus it's name Virtual Memory System) VMS was not first in being muti-user, commercially that was Unix.
3. Windows NT arrived in the late 80's, and not surprisingly ran on DEC VAX hardware as well as x86 based systems, as the chief engineer of NT came out of the VMS development team at DEC.
So NT got this idea from VMS which got it from Unix....
Unix was never implemented for PDP-11 by DEC. 3rd parties adapted several versions so that they could run on the PDP-11. A number of generations of "realtime" operating systems were developed by DEC for the PDP-11 and later the VAX-11 series.
Dave Cutler was on the teams for many of these OSes. Dave Cutler left for Microsoft to design Windows NT. Dave Cutler *never* implemented an OS for PDP-11 based on Unix. In fact, he *disliked* Unix.
And no, Unix did not invent access control. I sense that you need Unix to be some type of god-like hero. It is an operating system, and an aging one at that. Cool off.
BSOD happens when the kernel detects memory corruption. With a hybrid monolithic kernel like Windows that means all bets are off and continuing could very well case damage more damage.
Even if the memory corruption happens in an USB driver, it can overwrite critical kernel memory.
Incidentally, you *do* get more information. The kernel will initiate a kernel dump which can be investigated later.