Jump to content

Talk:Preboot Execution Environment/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

PXE page working premises

Based on user:Drmies request I'd like to propose a set of premises and edition guidelines that could work as a frame for the future work on this PXE page.

________________________________________________________________________________________________________________________________

Premises:

  1. PXE is a net booting technology built upon a publicly available specification made by Intel and other companies.
  2. The use of the PXE specification is free not requiring fees or royalties of any kind.
  3. PXE recently evolves from a (legacy) BIOS based technology to a (new) (U)EFI based technology.

Editing guidelines:

From the above premises we can propose that the PXE Wikipedia article should :

  1. Only revolve around the PXE public specification (BIOS based) and its recent extension to the (U)EFI environment.
  2. Include references to related predecessor technologies only when they are intimately linked to PXE and the net booting process itself.
  3. Include references to related parallel technologies only when they belong to the same equivalence class (i.e. BSDP (NetBoot) for MACs)
  4. Not directly include comparison with derivative technologies as those discussions can be carried out at the derivative technology corresponding WP pages.
  5. Link to representative PXE projects only when supported by independent sources proving the linked project relevance and quality.

________________________________________________________________________________________________________________________________

Please consider this just a starting point feel free to cast your comments an/or proposals. 213.37.84.214 (talk) 10:49, 16 December 2013 (UTC)

Drmies Thank you. Please consider the PXE page is still locked; I cannot really find who's the one that did it; I think unlocking it is a good idea. What do you think? 213.37.84.214 (talk) 15:32, 16 December 2013 (UTC)
no problem on my side, but you please stick around and see how the thing develops 213.37.84.214 (talk) 16:06, 16 December 2013 (UTC)
  • Agree pages should be protected at the lowest possible level. NE Ent 03:21, 19 December 2013 (UTC)
  • I question the "editing guidelines" proposed above. We already have more than enough guidelines, and I don't think, we need a specific set of guidelines for this article on top of them.
Over the course of the past months, the IP has demonstrated, that he is incapable of understanding and following our guidelines, and he hasn't brought forward a single useful edit on this or any other topic. The editing guidelines proposed by him are clearly tailored at removing some of the existing contents and links to related technologies from the current article, clearly showing that the IP's intentions have not changed at all. Therefore, considering to release the semi-protection sounds like a very weird idea to me. Before we can trust this IP again, he should learn to write and edit articles on a few other topics, for example by writing an article on SERVA or even better articles on topics totally unrelated to PXE.
While I can see some of the contents moving to other articles in the long run (rather than just being deleted), this does not address the article's actual issues. The main issue of the article in its present form is that it leaves a lot to be desired in explaining PXE as is. So, we should think about adding a lot of contents rather than to delete some. However, we don't need extra guidelines for this. If the IP wants to discuss PXE at a more detailed level, he can present his content drafts on this talk page, and if they are fine, other editors will incorporate them into the live article.
--Matthiaspaul (talk) 14:49, 19 December 2013 (UTC)
I think a clear and small set of complementary editing rules specifically tailored to this PXE article could really help to avoid the kind of problems we have faced lately with you and Widefox. That's why I took the time to post this humble draft after Drmies request.
The presented guidelines are tailored to talk about PXE and they pretend to clearly set the boundaries for doing so. Yes; some stuff like the mention of the warez based project ERPXE and the like has to be gone, but the guidelines also i.e. set the rules at point 3) for the inclusion of parallel technologies like Mac BSDP which mysteriously is not even mentioned in the current article.
Therefore we cannot say the strategy here is just "removing" things; No one wants an empty PXE article but no one wants a PXE article full of unrelated/controversial material either. what do you think?
213.37.84.214 (talk) 22:15, 19 December 2013 (UTC)
Please pardon me, but I think this whole thing is totally ridiculous. So much effort went into so little new content. — Dsimic (talk) 22:36, 19 December 2013 (UTC)
Well I have just seen the PXE page history and I saw your most important contribution was probably adding links to the PXE derivative project iPXE; a project that would be impacted for these guidelines as discussing its virtues or flaws would be considered better done in an iPXE page than here. I can understand your disappointment but I think we would get a better PXE page if we do not discuss iPXE here. What do you think?
213.37.84.214 (talk) 23:11, 19 December 2013 (UTC)
Well, back at the time I added a short paragraph describing the availability of open-source PXE implementations, and iPXE was used there just as a reference. I'd really like to know what's wrong with that... Why would mentioning open-source implementations be considered a bad thing? — Dsimic (talk) 23:48, 19 December 2013 (UTC)
Mentioning open-source stuff is not a bad thing "per se" the problem here is that at the moment the PXE page has become too much "iPXE" centric. If you see the references, links, and the overall spirit of the article everything seems to revolve around a project that being in fact a "derivative" of PXE so far has not ever produced a single official specification document. iPXE could be very well matched with other even more famous open-source PXE projects like i.e. Syslinux/Pxelinux but this WP PXE page has not a single mention of it.
We pretend to talk about the "standardized" PXE protocol here; and this is said at the first point of the guidelines draft. Probably we should leave the discussion/comparison/analysis of derivative technologies at the corresponding derivative technologies WP pages; and this is said at the 4th point of the guidelines draft. I think it is important setting the boundaries of what should be discussed here and what is better discussed somewhere else. This way we might not promote iPXE here but surely we'll get a better PXE page. Don't you agree?
BTW I have undone your inclusion "or open-source PXE implementations" from the 1st guideline as it is in fact contradictory with the spirit of discussing only the PXE specification here and no particular derivative projects no matter if they are open-source or not. Probably next time instead of directly editing the guidelines draft it would be a better idea discussing here the proposed change first in order to avoid other inconveniences.
213.37.84.214 (talk) 08:51, 20 December 2013 (UTC)

Please pardon me, but I'm a bit confused about your intentions with the whole thing? And why are you hiding behind an IP address all the time? Regarding why do we have "too many" iPXE references, that's because this article had next to no references before I added a few of them, while adding that short paragraph describing iPXE as an open-source PXE implementation. Please, why don't you, for example, go ahead and add a few other good references — this article really needs them, as the hatnote states anyway? Let's put function ahead of form, if you agree — many rules don't help if no real work is done. — Dsimic (talk) 14:06, 20 December 2013 (UTC)

Also, calling an article "iPXE-centric" just because of a two-line paragraph (which is not even mentioning "iPXE" as an acronym) is just ridiculous, if you agree. — Dsimic (talk) 14:12, 20 December 2013 (UTC)

I'm not hiding; do you think that my IP says less about myself than being registered with a yahoo or gmail account? sure you don't.
About the references today 50% of them (3 out of 6) point out to the iPXE project webpage. Besides that, the tone of the article transmits the false idea that iPXE is the way to go and that PXE is somehow the "past" but the real thing is that iPXE is not a standard and that Intel has incorporated the PXE concepts within the brand sparkling new (BIOS successor) UEFI technology. Then we rather get a clear explanation about the PXE specification here; also why should we discuss iPXE here when iPXE has its own WP page?
About adding references myself well the article is still locked; hopefully that is going to be fixed soon. In advance I can tell you that I consider we should add single references pointing out to Isolinux/Pxelinux and gPXE/iPXE (remeber iPXE was really a fork of the gPXE project; it didn't come directly as a PXE derivative).
Also let me tell you that the references section is something that should come after getting done the article core; and that that core should be made out of explaining as simple as we can the PXE standard.
I really cannot understand why this article creates so much trouble; it should be as easy as to explain in lay terms an already written standard don't you think?
213.37.84.214 (talk) 15:08, 20 December 2013 (UTC)
Why don't you open yourself a Wikipedia account, and you'll be able to edit this article? It's only semi-protected. Could you also, please, provide a quote from the article, where that "false idea" is actually transmitted? — Dsimic (talk) 16:37, 20 December 2013 (UTC)
i.e. 1 the sentence Besides proprietary PXE boot images, alternative non-standard open source implementations transmits the idea tha PXE is proprietary when it is not and that the open source implementations are the way to go. I have added the word non-standard in order to diminish a bit the distortive effect of that sentence.
i.e. 2 the sentence "providing even broader possibilities like booting over HTTP or iSCSI" well that's something that is said even before describing the PXE protocol; shouldn't that be on the iPXE WP page?
213.37.84.214 (talk) 17:26, 20 December 2013 (UTC)
Quoted sentence #1 isn't saying that PXE is proprietary; it's saying that besides proprietary PXE implementations, there are also some open source implementations. Sorry, but I really can't figure out what's wrong with that? I've just edited that sentence for some additional clarity and improved readability, please check it out.
Quoted sentence #2 just explains additional possibilities provided by some of those open source implementations, and "iPXE" isn't mentioned there. Should we add a link to iPXE there, as an example? That brief summary should be useful to readers, letting them know what key additional benefits are there to be offered by those open source PXE boot images — if you agree. Also, the whole thing is described in more detail on the iPXE page; that's just a brief summary.
I've also moved one sentence between sections, cleaning it up along the way, for a possibly improved flow and better readability; please check it out.
— Dsimic (talk) 18:26, 20 December 2013 (UTC)
It is not about what it's said but more about what it's implied. I really do not think we have to mention the not applicable negative concept of proprietary implementations nor having an almost spam link to iPXE claiming to have more features in a point of the article where the PXE protocol has not been even described yet.
I also have just seen you added NetBoot as "See also" but NetBoot is not an equivalent parallel technology; it is in fact an application implementing BSDP. BSDP is the protocol that should be quoted here instead if we follow guideline #3.
Dsimic I see you have good intentions and I'd like working on this article with you and people like you but at this point lets get focused on defining the guidelines and next we can all move to the editing phase when the article is unlocked and everybody can edit the thing. Don't you think that would be better?
213.37.84.214 (talk) 08:33, 21 December 2013 (UTC)
Regarding your suggestion on changing the order in which PXE is actually presented, I agree that's a good point; I've edited the article by reordering two sections, please check it out. On the other hand, iPXE has more features than BIOS-based proprietary PXE implementations; please pardon me, but that's a verifiable fact, not a spam.
I've checked the edit history, and it wasn't me adding NetBoot into the "See also" section. It was already there, before my first edit performed on this article.
Once again, could you please explain why are you refusing to create a Wikipedia account, what would allow you to edit this article? It's only semi-protected. — Dsimic (talk) 00:18, 22 December 2013 (UTC)
I'm glad you agree on the article reordering considering a top-down priority focused on the PXE standard.
About the iPXE link I consider it becomes spam when those "extra" features that iPXE has are mentioned before describing PXE itself.
I also want to present here a warning note on those additional iPXE features; PXE is only able to retrieve NBPs (Network Boot Programs) by TFTP, TFTP is an UDP based file transfer protocol that has serious problems when its transfers face alternative paths (routing) or they need to cross NAT (Network Address Translation) devices, then it results virtually impossible to retrieve an NBP from an Internet host; the NBPs must be intranet hosted. On the other hand iPXE is able to transfer NBPs using the TCP based HTTP protocol then you could easily retrieve NBPs from anywhere in the world. For many people this represents a serious security risk; an attacker could trigger the booting of malicious code located anywhere in Internet just using this iPXE extra "feature", all of this in a moment of maximum vulnerability as a booting target never has a working anti-virus layer.
I could also mention additional drawbacks like i.e iPXE is not a published standard, it doesn't have a big name like Intel behind it, it presents serious compatibility/stability issues, etc. Then if we want to talk about iPXE I really think we should do it in a more comprehensive/unbiased way at the WP page, I still think the PXE page should only contain a "neutral" reference to gPXE/iPXE w/o getting into their features or drawbacks.
About NetBoot, sorry when I looked at it it showed that it was added in your last edit but I could've made a mistake.
About registering (please correct me if I'm wrong) but with the article being semi-protected even if I register I still need the authorization from the article locker in order to post. Drmies has said he was willing to unlock the article and NE Ent has agreed then I think it is just a matter of time for him being around and fixing the thing.
213.37.84.214 (talk) 14:52, 22 December 2013 (UTC)

Hm, why would TCP be in a better position when it comes to traversing NATs? Both TCP and UDP are running on top of IP, and they're the same from that point, regarding the NAT traversal itself. Back at the time – for example – I used TFTP for booting some Cisco equipment in quite complex network layouts, and it all worked very well.

I agree that iPXE isn't the standard, it's just an open-source PXE implementation, with some additional features over the PXE itself. Please pardon me, but I really don't understand what's wrong with adding more features? Also, I strongly disagree that big names are required for stability and compatibility of a software product. Just as a small example, how many buggy BIOSes have you encountered, and weren't all of them backed by their large manufacturers? :)
No worries about NetBoot, it's quite easy to become slightly confused in those lengthy edit histories. :)
The article is now unprotected, so you can go ahead with editing. While it was semi-protected, you needed to become WP:Autoconfirmed, what boils down to having ten edits in total.
— Dsimic (talk) 00:32, 23 December 2013 (UTC)

well the whole thing is related to the TFTP protocol nature and how (i.e. in Linux) the modules netfilter/conntrack handle the tracking of TCP or UDP traffic. UDP traffic is not as simple to track (Required by NAT) and is sensitive to inverse order arrival; while this is pretty common in Internet scenarios sure you have not experienced these problems in your "intranet" network layouts. It is curious how this TFTP protocol "drawback" ends up "somehow" being a security feature. Remember Intel added full TFTP support into their new (U)EFI specification.
About the extra features that iPXE adds, again, there's nothing bad about them if we put the whole thing in perspective. i.e. If you are a big "bank" migrating to i.e. Windows 7 and you are planning to do that using your network then sure you will not be interested in iPXE; did I hear why? well because you will be reluctant to re-flash your NICs (chainloading does not always work well), because you will need a standard, documentation, you will need a big name supporting your decision, summarizing you will want your back covered if anything goes wrong! on the other hand if you are a computer geek that likes to test and play at home with all the undocumented toys you can find out there for sure the iPXE HTTP booting feature might result "cool" to you. As an example Microsoft in their RIS/WDS/MDT/SCCM products didn't implement iPXE they are still loyal to PXE even when they did improved TFTP transfer speed by the use of the negotiated windowsize variable (today IETF draft).
As you can probably agree now, recommending/referencing iPXE extra features should include lot of additional considerations that must be addressed somewhere; I think the PXE page shouldn't be place for that.
The article is now unprotected, I'm taking a few days off and later we can start planning the article improvement hopefully based on the outlined guidelines if there's not a sustained opposition to them.
213.37.84.214 (talk) 09:38, 23 December 2013 (UTC)
Please pardon me, but the whole thing with TFTP being unable to pass through NATs and firewalls is next to a nonsense. TFTP is no different from DNS (excluding zone transfers), for example, when it comes to traversing NATs, firewalls and the whole Internet infrastructure; we all know that DNS works pretty well. Regarding the UDP's connectionless nature, TFTP provides internal mechanisms for retransmissions of lost packets, as per RFC1350.
The only reason why TFTP mainly isn't used outside intranets is it's lacking any security mechanisms, meaning no auth methods are built into TFTP. That's the reason why TFTP is perceived as to be used in local networks only, not because it can't go through NATs and/or firewalls.
Please, let's remember that – at the same time – UEFI supports iSCSI as well, what opens it up to those "security issues" you're referring to. iSCSI works on top of TCP, so it's as "vulnerable" as HTTP from the point of traversing NATs etc.
Hm, what would be the benefits of booting over HTTP in case of booting Windows over network? In such "corporate" cases, you'll end up using whatever your hardware supplier and Microsoft tell you to do and use. There's no freedom of choice is such environments; do you think that IT employees of those banks are looking into Wikipedia while searching for their next solution? :)
Regarding the big names, I had bad experiences where those mean next to nothing, regarding solving actual issues. There's no doubt such companies have great people, but it's impossible to reach them through many layers of bureaucrats and sales people, making the whole "big names" thing providing no real back coverage. Just as a small example, why do you think Google is pumping money into CoreBoot, instead of jumping onto Intel's UEFI train? :) Anyway, that's not directly linked with this article.
I'm a bit confused about you saying that someone wants to "implement iPXE?" How can iPXE be implemented? iPXE isn't some kind of a standard or protocol, it's just the name given to an open-source PXE implementation, nothing more. It could've been named "Santa" instead, and how could a Santa be implemented? :)
Once again, iPXE isn't mentioned anywhere within the article, except in the "See also" section. If you really insist on removing the mentioning of any additional features provided by open-source PXE implementations, and leaving just a note of existence for those open-source PXE implementations, I'm Ok with that.
— Dsimic (talk) 15:45, 23 December 2013 (UTC)
TFTP has a dynamic port assignation that NAT doesn't like; it is related to the ability to allow and track an incoming packet on a port that was not the one used in the original outgoing request, DNS does not have that problem. Please read RFC-1350; TFTP and NAT (I can add firewalls) do not mix well. Also your comparison with DNS is not applicable when considering packet order inversion produced by alternative routing paths, remember a TFTP stream could involve hundreds of MB plus the protocol recovery features do not prevent errors occurring again and again and eventually reaching a transfer abort condition after a # of retries.
About UEFI it is true it adds iSCSI; but it also adds SecureBoot, then the security issues that you mention are very well addressed. Something very different happens on an iPXE scenario when just mistakenly flashing a malicious firmware or someone attacking your PXE server can lead to your PXE clients booting up from an NBP retrieved from China or wherever.
About big names, we need to see who's who in this game; it is not weird thinking of Google fighting against Intel for something that could imply lot of money, it is also not weird an IT manager rejecting an iPXE based solution if there's an standardized, more stable, more secure alternative arround.
You "implement" iPXE when you decide to flash NICs, or booting their NBPs and chainload from your PXE server etc. iPXE is not just a PXE implementation, iPXE changes things specially at the client module, remember PXE is not only the server protocols but also the Bios extension API running at the client. then it is not just a name.
About references Yes; I agree and I'm glad you are OK with that; The idea is not mentioning more than the existence of PXElinux, gPXE/iPXE as implementations and/or derivatives of PXE but w/o mentioning extra features, See how many things we were discussing about them and how confusing they could result even to educated people; this stuff is better discussed at their page.
213.37.84.214 (talk) 20:18, 23 December 2013 (UTC)
I've just reread RFC1350 in detail, and I stand corrected. You're right, TFTP involves dynamic ports allocation, and that requires support in firewalls (similar to FTP, for example). Linux has support for that, as part of NetFilter's connection tracking, though it requires to be enabled etc. I apologize, and just for reference, here's an excerpt from the RFC1350:
The transfer identifiers (TID's) used by TFTP are passed to the Datagram layer 
to be used as ports; therefore they must be between 0 and 65,535.

[...]

In order to create a connection, each end of the connection chooses a TID for 
itself, to be used for the duration of that connection.  The TID's chosen for 
a connection should be randomly chosen, so that the probability that the same 
number is chosen twice in immediate succession is very low.  Every packet has 
associated with it the two TID's of the ends of the connection, the source TID 
and the destination TID.  These TID's are handed to the supporting UDP (or 
other datagram protocol) as the source and destination ports.  A requesting 
host chooses its source TID as described above, and sends its initial request 
to the known TID 69 decimal (105 octal) on the serving host.  The response to 
the request, under normal operation, uses a TID chosen by the server as its 
source TID and the TID chosen for the previous message by the requestor as its 
destination TID. The two chosen TID's are then used for the remainder of the 
transfer.

[...]

Note: TFTP passes transfer identifiers (TID's) to the Internet User Datagram 
protocol to be used as the source and destination ports.
Regarding the sizes of data transferred through TFTP and retransmits, that's exactly what crossed my mind after I've posted my last reply. Just as you said, in case of large amounts of data, retransmits handled within TFTP can pile up, resulting in such transfers being aborted. It's no wonder that (large) DNS zone transfers are using TCP, versus (small) DNS queries running on top of UDP.
Speaking about booting malicious images over iPXE in "tight" corporate environments, probably such networks would also involve firewalling of their outgoing traffic, and such hosts probably wouldn't be able to surf the web at all. But then again, surfing the web would probably remain enabled, with some "L7 filtering" in place or whatever. Speaking about changing what gets loaded through iPXE, isn't the whole security scheme broken if anyone reaches the point where changing that on workstations is possible at all, once it's been configured?
On the other side, there are some other environments, where an open-source PXE implementation would be much more welcome than a closed one. Those are the environments preferring to have the source code available, so it can be audited, verified for correctness, checked against backdoors etc.
As a side note, I'd say that the whole discussion about some corporate environments choosing iPXE or not, is simply pointless. As I already wrote, they're going to use whatever they're told to by their computer hardware supplier and Microsoft. I'd bet they don't even know what PXE is, or care about, as the whole "network boot" thing is delivered to them as part of some Microsoft's "click-click" thingy, with some fancy names sticked to it. :)
— Dsimic (talk) 21:09, 23 December 2013 (UTC)
TFTP has survived on net the booting arena because today with high quality networks, if there are no high round trip delays and no more than a couple of network jumps between client and server the overall result is not bad, specially when using a "windosize" strategy. Internet transfers on the other hand are virtually impossible "but" from a TFTP point of view they are neither needed or "wanted".
The iPXE security thing can be also seen like this; a Windows Vista/7/8 net install involves maximum a 200MB TFTP transfer (Boot.wim) the rest of the OS being installed is transferred using a Microsoft share. If you use windowsize=32 on a GBit network that transfers could take less than 20 secs, the whole OS install takes about 20 minutes, then in order to improve the 20 seconds transfer out of 20 minutes you tell me I have to flash my NIC with a non standard iPXE firmware plus open the gate to a potentially malicious HTTP transfer?? No way; thanks.
I think you are mistaken about open/closed-source when it comes to a piece of firmware that comes factory embedded within your NIC. No one really needs the source code of the firmware embedded within HDDs, DVD readers, Video Cards, NICs with standard PXE firmware, etc, etc. Can you imagine a situation where some company might require the source of every piece of firmware a PC has? I cannot.
I could agree with you on how companies decide to implement an iPXE solution; then let me tell you hardware manufacturers (with a couple of isolated exceptions) didn't add iPXE, Microsoft didn't adopt iPXE either.
213.37.84.214 (talk) 22:20, 24 December 2013 (UTC)

When did I say that Windows world is going to use anything that's reaching outside of their little boxed "stick to the defaults" perception? :) On the other side, if people sticked to the "defaults", we'd have no open-source operating systems etc., and the world would've been a much darker place. At the same time, it's Wikipedia's mission to provide a WP:NPOV, so everything should be clearly listed and presented; we're not just listing industry's "best practices" here.

It all depends on the company, its size and its needs. Some companies want (or need) to have greater control over their infrastructure, some don't. If all companies took the "stick to manufacturer's things" route, we'd have no products/projects such as CoreBoot, iPXE, MySQL, Open vSwitch, etc. In my opinion, having open-source implementations can only be a good thing. Maybe PXE isn't the best example per se, but that's the general idea.
Regarding the availability of source code for various firmwares, back at the time people would've killed for DVD devices firmwares' source code; even now people would like to get their hands on those source codes, so things like DVD recording quality measurement could be taken further out of the proprietary software area. Also, having source code for a VGA BIOS is a great thing, as you need one for making a virtualization solution such as QEMU, for example. Also, many people would just love to get their hands on source codes of current SSDs firmwares. Those are just a few examples.
It all depends of what a company (or group of people) need, or want. Please don't get me wrong, but if people weren't thinking outside the box, we'd also have no Wikipedia, right? Why would anyone in the world go and write another encyclopedia? :) — Dsimic (talk) 23:31, 24 December 2013 (UTC)

Do not worry; WP:NPOV at the PXE page implies to present PXELINUX/gPXE/iPXE w/o taking sides and that's what we are going to do by just mentioning w/o further detail those projects here :)
I love open-source but I also love pragmatism; I never needed firmware source code; I'm glad that kind of source code is not easily available out there then we have less chances of opening the door to i.e. firmware viruses. But I also understand your point of view considering the examples you just gave. I also agree PXE is not the best example for that need.
Going back to PXE I think we are good; after describing how the protocol works we mention this descendant protocols and people can talk about their virtues at their pages and I will be also there talking about their flaws just to achieve the required WP:NPOV ;-)
213.37.84.214 (talk) 01:37, 25 December 2013 (UTC)
Well, I'd love if I could get my hands on source code of the Award BIOS used on one of my motherboards, so I could fix a bug related to the GART mapping – for example. :) Of course, I've reported that bug to the motherboard manufacturer, and they simply don't care, refusing to fix anything that isn't breaking Windows. Go figure. :)
Regarding the availability of firmwares' source codes, I'd say that it would be actually a good thing. Those codebases (primarily for BIOSes) are totally ancient, quite buggy, and prone to various security issues. Just as an example, [http://www.amazon.com/BIOS-Disassembly-Ninjutsu-Uncovered/dp/1931769605 this book] (now freely available) resulted in some of the BIOS security issues being fixed by BIOS manufacturers; those issues weren't publicly known before the release of that book. Who knows what else is hiding within those binary blobs, and what knowledge is circling in blackhat communities? If their source codes were publicly available, many people would be fixing them; that's a classic example of (false) security through obscurity. Of course, there are also incidents like this one, and let's just remember that UEFI is taking a much more open approach.
On the other hand, I agree that pragmatism is also very important... It would be completely unreasonable to expect from an IT department of some bank to spend their time hacking iPXE or doing something similar; their primary job is to keep the printers running, with enough toner, and jam-free. :)
— Dsimic (talk) 03:44, 25 December 2013 (UTC)
I've just edited the article, so those additional features offered by open-source implementations are no longer mentioned. Please, check it out, and I'm sure you'll agree that's rounding up a valid WP:NPOV. — Dsimic (talk) 04:05, 25 December 2013 (UTC)
@213.37.84.214: Happy new year! Just checking, are we going to continue our work on improving this article? :) — Dsimic (talk) 22:24, 6 January 2014 (UTC)
Any news? :) — Dsimic (talk) 00:39, 22 January 2014 (UTC)
Your comments suggest a claim of ownership of the article. You have to work with others. ViperSnake151  Talk  16:56, 20 December 2013 (UTC)
@ViperSnake151: To whom are you referring, please? — Dsimic (talk) 17:23, 20 December 2013 (UTC)
Yeah I was talking about the IP editor. ViperSnake151  Talk  17:30, 20 December 2013 (UTC)
If you are talking about me please, I'm not claiming ownership of anything; I'm working with everybody here (included you) to come up with an agreement on how to develop an article on the PXE standard. Sorry if I've transmitted (or you got) the wrong idea.
213.37.84.214 (talk) 17:26, 20 December 2013 (UTC)
ViperSnake151, there can be no ownership since the IP can't even edit the article. (I will look into the protection issue.) The very fact that they're here, discussing things, is sufficient sign of non-ownership. You can either further this discussion and thus the article, or stay out: baseless accusations are unhelpful. Drmies (talk) 18:09, 22 December 2013 (UTC)
  • Can I just point out that the IP is perfectly in their right to continue editing as an IP? Whether you like it or not, IPs are humans too (yeah, that's an essay, but the policies and guidelines it links to are legitimate). So please stop harping on that point and address the substance of what the IP editor is saying. Thank you. Drmies (talk) 18:07, 22 December 2013 (UTC)
  • The ability of IPs to edit far more than an essay, it's a Founding principle of all WMF projects; as the linked page clearly states People who strongly disagree with them are nonetheless expected to either respect them while collaborating on the site NE Ent 19:12, 22 December 2013 (UTC)
  • Please don't get me wrong, I'm respecting everyone on Wikipedia, and here we're all just letters on screens. I wasn't dwelling on with the issue of IP addresses and editing, I was more asking why this editor isn't creating an account, so he/she can start improving the article. If I was him/her, I'd open myself an account and start working. :) However, the article is now unprotected, and I'm looking forward to the article becoming better! — Dsimic (talk) 00:53, 23 December 2013 (UTC)
  • I've unprotected the article: I see that the IP editor is discussing things constructively; if anything, it's the registered accounts that pay more attention to other matters than to article discussion. NE Ent agrees that protection should be done at the "lowest possible level", which I take to mean unprotection--Ent did not indicate that they think allowing IP edits is a problem, nor did anyone else. IP, you don't need mine or anyone else's permission to edit, but remember, take it easy and don't abuse the privilege. Good luck, Drmies (talk) 18:14, 22 December 2013 (UTC)
  • Please pardon me, but my focus was all the time on improving the article, and discussing that with 213.37.84.214. As already said above, I'm looking forward to the article becoming better! — Dsimic (talk) 01:01, 23 December 2013 (UTC)
  • Just as I wrote above, I'm respecting everyone on Wikipedia, and I was talking about the IP address only from the point of enabling this editor to actually edit this article. — Dsimic (talk) 01:53, 23 December 2013 (UTC)
  • Thanks Drmies & NE Ent for your understanding. I'm taking some time off these days but I'll be back soon trying to help improving this article.
If possible I'd like to count with your support on the proposed guidelines; that will surely help if some edit conflict comes up in the future.
213.37.84.214 (talk) 08:30, 23 December 2013 (UTC)
Count me out, IP, and get someone who knows this subject matter. Ent is smarter than me, and I'm sure there are plenty other editors who can help, or admins who can referee if need be. Drmies (talk) 14:38, 23 December 2013 (UTC)
Good, I'm definitely counting on NE Ent he has been always a valuable independent voice here even on troubled times.
213.37.84.214 (talk) 20:18, 23 December 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Preboot_Execution_Environment/Archive_3&oldid=1083530492"