geographomics

The way around it is, rather than opening the CSV file directly, to create a new blank workbook and import the CSV file using Data --> Get External Data --> From Text. This opens the Text Import Wizard and from there one can define the datatype for each column - set it to Text (instead of the default, General) and it won't be interpreted as a number.

Another way is to rename the .csv file to be .txt instead, and load it in normally. This triggers the Text Import Wizard upon opening, and the rest is as above.

Also to do this programmatically, one can use the VBA function Workbook.OpenText, and specify the data types via the FieldInfo parameter.

A model containing only neurons may be too simplistic - glial cells also seem to modulate cognition in ways that haven't yet been fully elucidated. Then you also have rather more asymmetric synaptic behaviours such as volume transmission, where the neurotransmitter is diffused across a less well-defined area, rather than being kept neatly within a shared synaptic cleft.

Preserving the connectome is probably insufficient for full restoration. Even if you could record the entire structure of the brain at the synaptic level, you're still missing the functional states of the neurons and glial cells that it is composed of. It would be like trying to reconstruct a piece of software solely from its call graph.

Apple uses Shazam as the backend for their music identification service on iOS 8, so at least they're not having to compete there.

If that anecdote is true, it means the medical school would have a bias against anyone who doesn't identify as Hispanic/Latino, and not necessarily a specific bias against Asians.

Yes but even if it could be confirmed that racial quotas that are significantly unfavourable toward Asian applicants exist for some medical school admissions, that doesn't mean it was the reason for your friends being rejected.

We just don't know if they would have been accepted in an equivalent system without these alleged discriminatory policies, because gaining a medical school offer depends on such a myriad of other factors.

I think that unless you're privy to all the information that the admissions staff are using to judge acceptance, including the quality of the competition and a myriad of other factors that you or I may not have considered, it's a bit of a stretch to assume your friends were racially discriminated against. I don't know how many people you're talking about, but assuming it's a relatively small number, the rejection of most/all of your Asian friends to study medicine could just be down to chance.

It's difficult to conclude that from those statistics alone, as we don't know the distribution of MCAT and GPA scores within the self-identified Asian applicants - a higher mean may be because it is positively skewed. In that regard, it would be interesting to see the median values too. Or the stats for the rejected cohort.

Describing it as "just a mod" rather downplays the significant development effort that OS X has undergone since its inception. The code originally borrowed from Mach and BSD only applies to some parts of the kernel, and a few userspace programs.

That's an interesting point, and indeed NT has a curious history in that regard - Microsoft was originally planning an OS/2-based API as the dominant one, and it was only due to the success of Windows 3.0 that they ended up adapting the Windows API to 32 bits.

Microsoft has always been dominated by backwards compatibility constraints so there probably wasn't much scope for a massive redesign of the API, as it was in their best commercial interests for 16 and 32 bit Windows APIs to match as closely as possible, to ease porting of third party software.

Maybe it's just that the accepted applicants were of the same quality or better, in terms of their predicted suitability to practice medicine. The fact is that not everyone can get into such highly competitive programmes, and unfortunately some have to lose out.

But OS X literally is a Unix derivative. Its precursor NeXTSTEP was built on top of the Mach kernel and BSD.

In comparison, Windows 10 has its roots in the Windows NT lineage (starting with NT 3.1, and including Windows XP), which is separate from the DOS-derived Windows line that ended with Windows ME.

(That said, I agree that he was just trolling.)

In the case of wanting to stick to a text-only workflow, rather than taking advantage of the structured data features, then you only need a tool that converts the binary log format to your preferred text format. Which isn't too arduous. In systemd that would be journalctl, in Windows anything that can use the event log API such as Powershell or many other utilities.

The examples I posted above were just to show the equivalent capabilities in Powershell but really it's all flexible enough to use whatever you like.

That's not a limitation of the Event Log system itself, as you can easily write freeform text in the message rather than building it up with localised strings and structured data, e.g. https://msdn.microsoft.com/en-us/library/6w20x90k(v=vs.110)....

This is also just anecdotal, but I used to work with a Chinese sysadmin (I was in the UK, he was in China) who found it much more preferable to work on the localised Windows servers we had installed over there, as all the UI and messages were in his native tongue. I'm sure it was easier for him to gain expertise in the tools he needed for his work, than to become proficient enough in English to understand every obscure log or error message that the system might throw at him.

The difference is that a general purpose database typically organises data by fixed-size pages, so new data could be anywhere in the file as there is no guarantee of page ordering with regard to inserts. Whereas a specialised file format for logging would add new records at the end of the file (or in a circular fashion, depending on the design). But will have features similar to a database like a defined schema, and some form of indexing. This is true of systemd journals and Windows event logs anyway.

This isn't really true as the Windows event logs contain text as well as the other structured data, which you can search for using tools on the system. For example to search for some specific text in the system log using Powershell:

    Get-EventLog -LogName System | Where {$_.Message -Match "something"}

To process text as fields, as with awk, one would use the Split method (at least to start off with):

    Get-EventLog -Log System | Where {$_.Message -Match "something"} | %{ $_.Message.Split()[5,4] }

But as message text is often parameterised, it may be easier to take advantage of this data to get what you need. For instance, this command would extract the latest machine sleep and wake times from the system log, and calculate the duration:

    Get-EventLog -Log System -Source Microsoft-Windows-Power-Troubleshooter -InstanceID 1 | Select-Object @{n="SleepTime";e={$_.ReplacementStrings[0]}}, @{n="WakeTime";e={$_.ReplacementStrings[1]}}, @{n="SleepDuration";e={([DateTime]$_.ReplacementStrings[1])-([DateTime]$_.ReplacementStrings[0])}}

One can also sort and get unique values, just as in Unix-type systems - this command lists all drives defragmented in the past 30 days:

   Get-EventLog -Log Application -Source Microsoft-Windows-Defrag -InstanceID 258 -After (Get-Date).AddDays(-30) | Select @{n="Drive";e={$_.ReplacementStrings[1]}} | Sort Drive | Unique -AsString

So all the same capabilities are there, and then some. You just need to know your tools well enough to take advantage of it.

The system should provide a standard API for writing and reading logs. The precise format of the underlying log files is thus rather unimportant at this level of abstraction. Other than the logging subsystem and recovery tools, there's no need for any software to be accessing such log files directly (outside of the API functions). This is how Windows has done it for years.

The ease of recovering data from a corrupted log file depends on whether the logged events have been written as sequential records. This is true for text-based logs (the record delimited being a newline), and is also true of the most popular binary (i.e. structured) log formats, namely Windows event logs, and systemd's journals. Probably not if you're storing them in a more general purpose database though.

So this really is dependant on the file format of your log data, rather than an inherent difference between text and binary logging.

Another advantage of using structured data rather than free-form text is that you can more precisely encode the essence of the event, with fields for timestamp, event source, type of event, its severity, any important parameters, and so on. This permits logging to be independent of the language of the system operator. Rather than grepping for what is almost always English text, one can query a language-independent set of fields, and then, if a suitable translation has been done, see the event in one's native language.

When applied widely throughout a system, this leads to the internationalisation of log messages. Thus lessening the anglocentric bias in systems software. Windows has done this for years, at least with its own system logging (other applications can still put free-form text into the event logs if they wish.)

Windows systems have had better log querying tools than grep for years now, with a well structured log file format to match. It's good to see Linux distributions finally catching up in this regard.

Not that the log files on Linux are all entirely text-based anyway. The wtmpx and btmpx files are of a binary format, with specialised tools for querying. I don't see anyone complaining about these and insisting that they be converted to a text-only format.

Well the school website definitely exists: http://www.spse-po.sk/

And there is a github repo for his "upload.it" project, which appears to be a collaboration: https://github.com/mochja/odovzdaj.to

The Wire Clothing brand appears to be a work in progress as of the start of this month: https://dribbble.com/shots/2003539-WIRE-Clothing-brand-label, https://dribbble.com/shots/2004870--WIP-Wire-Shirts

And VIDEBY, which was also a collaboration, seems to be a school project only: https://www.google.com/search?q="videby"+site:sk

So his work doesn't seem to be that much oversold, though I agree it would be nice to see more detail than a screenshot.

I wondered that too - apparently in Vista the PIN was only used to authenticate to the TPM and retrieve the volume master key (which in turn protects the key used to actually encrypt the drive).

More pleasingly however, in Windows 7 and onwards it is used to encrypt the volume master key as well, in pretty much the way you describe.

Microsoft's submissions for FIPS validation have some good detail on this - Windows 7 [see section 7]: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/1..., others: https://www.google.com/search?q=site:csrc.nist.gov+inurl:140...

For those who use BitLocker: although it is set up to use numeric-only PINs by default, you can configure this to allow any character - which would presumably increase the search space of brute force attacks against the PIN.

The relevant Group Policy setting is "Allow enhanced PINs for startup", and can be found in Windows Components → BitLocker Drive Encryption → Operating System Drives.

True, but neither is this: https://en.wikipedia.org/wiki/Kaliningrad_Oblast

Interesting paper, thanks for the link. However, I do wonder to what extent the extra hours are voluntary, and if this definition relates to working harder (rather than longer).

> The UMC is also the most hard-working class, who is carefully taking responsibilities for their families etc.

I very much doubt the veracity of this broad generalisation.

Indeed I'd be most surprised if there was any correlation between hard work and socioeconomic status, given that there are such a wide range of employment roles (including self-employed) in which one can work very hard, yet with such diverse financial rewards.

Not what you're looking for, but your comment reminded me of this: https://en.wikipedia.org/wiki/BLIT_%28short_story%29

For the downvoters: this recent paper gives a thorough overview on the known effects of repeated head injury, and the currently available evidence: http://ge.tt/2Y9BoiC2

In summary, his choice of sport does increase the risk of neurodegenerative disease presenting as dementia in later life, and CTE in particular has a distinct neuropathology that distinguishes it from other presentations at autopsy.

Of interest, this article has a comprehensive history of the phrase, and reasonably balanced portrayal of its utility: https://www.buzzfeed.com/alisonvingiano/how-the-trigger-warn...